From 70d8e0ad0efb2222501ab4550ceaef70b2649a80 Mon Sep 17 00:00:00 2001 From: Daniel Lemire Date: Mon, 27 Nov 2023 15:44:24 -0500 Subject: [PATCH] In some cases, Visual Studio, when compiling 32-bit binaries, gets 0*something == -0 even when the 'something' is positive, when the system is not set to compile to nearest. --- include/fast_float/parse_number.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/fast_float/parse_number.h b/include/fast_float/parse_number.h index a011a8c..239931a 100644 --- a/include/fast_float/parse_number.h +++ b/include/fast_float/parse_number.h @@ -202,7 +202,7 @@ from_chars_result_t from_chars_advanced(UC const * first, UC const * last, // We do not have that fegetround() == FE_TONEAREST. // Next is a modified Clinger's fast path, inspired by Jakub Jelínek's proposal if (pns.exponent >= 0 && pns.mantissa <=binary_format::max_mantissa_fast_path(pns.exponent)) { -#if defined(__clang__) +#if defined(__clang__) || defined(FASTFLOAT_32BIT) // Clang may map 0 to -0.0 when fegetround() == FE_DOWNWARD if(pns.mantissa == 0) { value = pns.negative ? -0. : 0.;