I wrote about Visual C++ incorrectly converting hexadecimal constants at the normal/subnormal double-precision floating-point boundary. It turns out that David Gay’s strtod() also has a problem with the same inputs, converting them all to 0 instead of 0x1p-1022.
I have emailed Dave Gay to report the problem; I will update this post when he responds.
Update 2/28/24
The bug is now fixed (after several iterations) and is available in netlib. Thanks to Dave Gay for the quick turnaround.
Typically, I use Gay’s strtod() to check the outputs of other conversion routines (examples: Visual C++, GCC and GLIBC, PHP). In this case, the roles were reversed: I used another C implementation, Apple Clang C++ , to check Gay’s strtod().
