Just found out the reason of mysterious data corruptions we've been having: (tested with glibc 2.3.2-r9 and glibc-2.3.3_pre20040207 compiled with gcc-3.3.2-r7) #include <stdlib.h> main() { printf ("%f\n", strtof ("+5.7344E+02", 0)); return 0; } prints: 0.000000 and #include <stdlib.h> main() { char foo; printf ("%f\n", strtof ("+5.7344E+02", 0)); return 0; } prints: 245504.625029
works over here ... maybe your CFLAGS are too aggressive ? you neglected to provide `emerge info` so i have no idea heres my setup: Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.6.3-rc2) CFLAGS="-pipe -march=pentium4 -O2 -frename-registers -fomit-frame-pointer -mfpmath=sse -mmmx -msse -msse2 -fdelete-null-pointer-checks -funroll-loops -ffast-math -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"
And here mine: Portage 2.0.49-r18 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.6.2) CFLAGS="-O2 -mcpu=i686 -pipe" Wouldnt think its too aggressive ;) A coworker just reproduced it in debian, and I did also on RHAS 2.1
hmm, well here's what i get on my different boxes using your test cases ... i guess i lied about getting the right answer ;) i tested on a bunch of different archs/glibc (including 2.2.5) here and they all produce diff answers (but none the right one :D) perhaps this is useful: http://mail.gnu.org/archive/html/bug-glibc/2003-11/msg00119.html
It's not a bug... gcc does not see a prototype for `strtof()' and so assumes the retval is int (try to recompile with `-Wall'). Correct way is to compile with `-std=c99' (or manually define "__USE_ISOC99" in case gcc is too old).
i saw that define in the stdlib.h file and when i tried to do #define __USE_ISOC99, i'd still get warnings when compiling with -Wall guess i must have mistyped the define when i last tried it ;)
