For the record, this is the program I used to confirm that it's a duplicate:     #include     #include     void main() {         unsigned short control_word = 0x37f;         asm ("fldcw %0" : : "m" (control_word));         printf("%lf\n", strtod("283686952306183", NULL));     } Perhaps it can help if anyone on WSL reports this again. On 9/25/2019 12:56:35 PM, Anastasios wrote: Having looked into it more, I found this is due to being on WSL, and it is a duplicate of https://github.com/microsoft/WSL/issues/830 [https://github.com/microsoft/WSL/issues/830], which, I see, you are already well aware of. Please excuse the noise. On 9/25/2019 10:51:53 AM, Rich Felker wrote: On Wed, Sep 25, 2019 at 09:32:35AM -0500, Anastasios wrote: > Hello, > > Consider this program, strtod.c: > >     #include >     #include > >     int main() >     { >         printf("%lf\n", strtod("283686952306183", NULL)); >     } > > With current musl master from Git: > >     $ musl-gcc -static strtod.c -o a.musl >     $ ./a.musl >     283686952306176.000000 > > By comparison, with glibc: > >     $ gcc -static strtod.c -o a.glibc >     $ ./a.glibc >     283686952306183.000000 > > The correct binary representation of this float is > >     0x42f0203040506070 > > but musl strtod produces > >     0x42f0203040506000 > > i.e., it fails to set the LSB. I examined this while ruling out printf as the cause. I can't reproduce this. My test program for strtod shows, for the input "283686952306183": d: 283686952306183 [0x1.020304050607p+48] [42f0203040506070] I suspect you miscompiled musl, possibly by passing in CFLAGS (perhaps from defaults in your environment?) that break floating point semantics. We test for and refuse to build if __FAST_MATH__ is defined, but GCC only defines it if you use -ffast-math, not if you manually enable one or more of the individual broken options that -ffast-math enables. Alternatively, it's possible that you have a broken compiler version that miscompiles floating point code. Rich