On 2020-01-08 09:58, Vincent Torri wrote:
the look at the official doc :
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strtof-strtof-l-wcstof-wcstof-l?view=vs-2019
as strtof is a function in msvcrt.dll, maybe it's a bug in the
implementation.
Could be, but one might have thought MS would have seen and fixed this
long ago.
Here are all tests so far
linux: DEBUG buffer 0x7ffdb3ad8ee0 final 0x7ffdb3ad8ee6 fv
inf errno 34
mingw64 (W10,64): DEBUG buffer 000000000068F970 final 000000000068F977
fv 1.#INF00 errno 0
mingw32 (W7,32): DEBUG buffer 009F2FD8 final 009F2FDF fv 1.#INF00 errno
0
mingw32 (XP,32): DEBUG buffer 003e2470 final 003e2477 fv inf errno 34
The last one was from a really old version of msys, circa 2012.
When these lines were added to the test program:
errno=0;
FILE *fp = fopen("this will not work","r");
fprintf(stderr,"DEBUG fp %p errno %d\n",(void *)fp, errno);
fflush(stderr);
all platforms correctly emitted:
DEBUG fp (nil) errno 2
So it isn't a general errno issue, it seems to be specific to strtof
(and possibly related
functions). Are these maybe wrapped up some way by mingw before
msvcrt.dll is actually called?
That might explain how errno gets lost.
Thanks,
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
