based on patch by Dan Gohman, who caught this via compiler warnings. analysis by Szabolcs Nagy determined that it's a bug, whereby errno can be set incorrectly for values where the coercion from long double to double causes rounding. it seems likely that floating point status flags may be set incorrectly as a result too. at the same time, clean up use of preprocessor concatenation involving LDBL_MANT_DIG, which spuriously depends on it being a single unadorned decimal integer literal, and instead use the equivalent formulation 2/LDBL_EPSILON. an equivalent change on the printf side was made in commit bff6095d915f3e41206e47ea2a570ecb937ef926.
commit 6ffdc4579ffb34f4aab69ab4c081badabc7c0a9a set lnz in the code path for non-zero digits after a huge string of zeros, but the assignment of dc to lnz truncates if the value of dc does not fit in int; this is possible for some pathologically long inputs, either via strings on 64-bit systems or via scanf-family functions. instead, simply set lnz to match the point at which we add the artificial trailing 1 bit to simulate nonzero digits after a huge run of zeros.
the mid-sized integer optimization relies on lnz set up properly to mark the last non-zero decimal digit, but this was not done if the non-zero digit lied outside the KMAX digits of the base 10^9 number representation. so if the fractional part was a very long list of zeros (>2048*9 on x86) followed by non-zero digits then the integer optimization could kick in discarding the tiny non-zero fraction which can mean wrong result on non-nearest rounding mode. strtof, strtod and strtold were all affected.
in certain cases excessive trailing zeros could cause incorrect
rounding from long double to double or float in decfloat.
e.g. in strtof("9444733528689243848704.000000", 0) the argument
is 0x1.000001p+73, exactly halfway between two representible floats,
this incorrectly got rounded to 0x1.000002p+73 instead of 0x1p+73,
but with less trailing 0 the rounding was fine.
the fix makes sure that the z index always points one past the last
non-zero digit in the base 10^9 representation, this way trailing
zeros don't affect the rounding logic.
just defining the necessary constants: LD_B1B_MAX is 2^113 - 1 in base 10^9 KMAX is 2048 so the x array can hold up to 18432 decimal digits (the worst case is converting 2^-16495 = 5^16495 * 10^-16495 to binary, it requires the processing of int(log10(5)*16495)+1 = 11530 decimal digits after discarding the leading zeros, the conversion requires some headroom in x, but KMAX is more than enough for that) However this code is not optimal on archs with IEEE binary128 long double because the arithmetics is software emulated (on all such platforms as far as i know) which means big and slow strtod.
this header evolved to facilitate the extremely lazy practice of omitting explicit includes of the necessary headers in individual stdio source files; not only was this sloppy, but it also increased build time. now, stdio_impl.h is only including the headers it needs for its own use; any further headers needed by source files are included directly where needed.
this will prevent gnulib from wrapping our strtod to handle this useless feature.
this affects at least the case of very long inputs, but may also affect shorter inputs that become long due to growth while upscaling. basically, the logic for the circular buffer indices of the initial base-10^9 digit and the slot one past the final digit, and for simplicity of the loop logic, assumes an invariant that they're not equal. the upscale loop, which can increase the length of the base-10^9 representation, attempted to preserve this invariant, but was actually only ensuring that the end index did not loop around past the start index, not that the two never become equal. the main (only?) effect of this bug was that subsequent logic treats the excessively long number as having no digits, leading to junk results.
this caused misreading of certain floating point values that are exact multiples of large powers of ten, unpredictable depending on prior stack contents.