MinGW - Minimalist GNU for Windows

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28.12.2012 11:01, sisyphus1@... wrote:
> Hi,
> 
> The demo program:
> 
> ################################# #include <stdio.h> #include
> <stdlib.h>
> 
> int main(void) { char * s = "inf"; char *endp; double z;
> 
> z = strtod(s, &endp);
> 
> printf("%f\n", z);
> 
> return 0; }
> 
> #################################
> 
> I build that program with: gcc -o strtod.exe strtod.c
> 
> When I build that with the mingw.org port of gcc-4.5.2 strtod.exe
> outputs 1.#INF00. When I build that with the mingw.org port of
> gcc-4.7.0 strtod.exe outputs 0.000000.
> 
> Why did this change ? Is there something I forgot to do when I
> upgraded ?
> 
> I much prefer that this 4.7.0 compiler (and the perls that I build
> with it) would numify "inf" and "nan" strings to infinity and NaN
> respectively - not to zero.
> 
> What are the options I have for getting the behaviour that I prefer
> ?
> 
If mingwrt was compiled without INFNAN_CHECK, and if it's mingwrt that
provides strtod for you (it's difficult for me to tell, but most
likely it is), then there's nothing you can do, short of re-building
mingwrt.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ3UigAAoJEOs4Jb6SI2CwiaIIAOHrjiEqv1oUtWDgZIbGhMJJ
IZQq8ZRMlD+kLA1DWg9f63fDfdqL8DeoS5sMBHaklG+Vxr8b0WZae7KBwlwqhjxm
0vu+XQjjL0MAUb5NChIL1jWyEUwsaqvYWNkYUkCzjW3MplJFVRHwNLBED399mkm0
4++K1mQbV9DUAuFj+clvdjxuLbdN6p+kp+ej63owQ8eWM55Ni2BwwrjjXQYFrH5V
eJ11GzFyt23W1LdSARkFEwGCgK3rIFRbbVEGEPs6ERABl0vmR8KdyZy+RwOcCHcm
B+Q+dRhE45yWHhGI2e9cMRTqirbV9SyHOwtrDZEY0TZMbU7Et9r3LWULjHJFu0Q=
=lvdb
-----END PGP SIGNATURE-----

> Date: Fri, 28 Dec 2012 11:22:09 +0400
> From: LRN <lrn1986@...>
> 
> > What are the options I have for getting the behaviour that I prefer
> > ?
> > 
> If mingwrt was compiled without INFNAN_CHECK, and if it's mingwrt that
> provides strtod for you (it's difficult for me to tell, but most
> likely it is), then there's nothing you can do, short of re-building
> mingwrt.

I think there _are_ other options.  One is to have strtod in the
sources compiled for the program, and make sure the INFNAN_CHECK is
set there.  Another is to have a small private library with the
"fixed" strtod, and mention that library on the link command line
before any system libraries.  Finally, one could downgrade (or
upgrade?) to another version of mingwrt, where this problem doesn't
exist.

>-----Original Message----- 
>From: Eli Zaretskii
>Sent: Friday, December 28, 2012 7:13 PM
>To: MinGW Users List
>Subject: Re: [Mingw-users] strtod has changed from 4.5.2 to 4.7.0
>
>> Date: Fri, 28 Dec 2012 11:22:09 +0400
>> From: LRN
>>
>> > What are the options I have for getting the behaviour that I prefer
>> > ?
>> >
>> If mingwrt was compiled without INFNAN_CHECK, and if it's mingwrt that
>> provides strtod for you (it's difficult for me to tell, but most
>> likely it is), then there's nothing you can do, short of re-building
>> mingwrt.
>
>I think there _are_ other options.  One is to have strtod in the
>sources compiled for the program, and make sure the INFNAN_CHECK is
>set there.  Another is to have a small private library with the
>"fixed" strtod, and mention that library on the link command line
>before any system libraries.  Finally, one could downgrade (or
>upgrade?) to another version of mingwrt, where this problem doesn't
>exist.

Thanks guys for the quick response.

I'm using a gcc-4.7.0 binary that I downloaded from mingw.org a month or two 
back - as mingw-get-inst-20120426.exe, I think.
The 'gcc -v' for it is provided below my sig.

Is there a suitable mingwrt that I can download and install over the top of 
the existing installation ?
That would be my preferred option.

How would I tell beforehand whether that binary has been built with 
INFNAN_CHECK ? ... or would I just have to try it out and see ?

Cheers,
Rob

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe
Target: mingw32
Configured with: 
../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions 
 --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug 
 --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs  
--build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.0 (GCC)

> From: <sisyphus1@...>
> Date: Fri, 28 Dec 2012 19:47:41 +1100
> 
> I'm using a gcc-4.7.0 binary that I downloaded from mingw.org a month or two 
> back - as mingw-get-inst-20120426.exe, I think.
> The 'gcc -v' for it is provided below my sig.

I think there's a newer GCC now, but if your problem is with mingwrt,
installing that won't solve the problem.

> Is there a suitable mingwrt that I can download and install over the top of 
> the existing installation ?
> That would be my preferred option.
> 
> How would I tell beforehand whether that binary has been built with 
> INFNAN_CHECK ? ... or would I just have to try it out and see ?

The latter, I guess.  Unless whoever built it will step forward and
tell for sure.

On 28/12/12 08:58, Eli Zaretskii wrote:
>> From: <sisyphus1@...>
>> Date: Fri, 28 Dec 2012 19:47:41 +1100
>>
>> I'm using a gcc-4.7.0 binary that I downloaded from mingw.org a month or two
>> back - as mingw-get-inst-20120426.exe, I think.
>> The 'gcc -v' for it is provided below my sig.
> I think there's a newer GCC now, but if your problem is with mingwrt,
> installing that won't solve the problem.
>
>> Is there a suitable mingwrt that I can download and install over the top of
>> the existing installation ?
>> That would be my preferred option.
>>
>> How would I tell beforehand whether that binary has been built with
>> INFNAN_CHECK ? ... or would I just have to try it out and see ?
> The latter, I guess.  Unless whoever built it will step forward and
> tell for sure.
>
>
Such poorly-defined semantics are why the proponents of 'defensive' 
programming regard strtod (and similar functions) as unsafe.

My two pennyworth: I would suggest writing your own wrapper around 
strtod following the suggestions at 
http://pubs.opengroup.org/onlinepubs/007904975/functions/strtod.html. 
"Since 0 is returned on error and is also a valid return on success, an 
application wishing to check for error situations should set /errno/ to 
0, then call /strtod/(), /strtof/(), or /strtold/(), then check 
/errno/". The wrapper can, of course, also check for infinity and nan. 
That way, you are insulated from whether somebody has defined a flag (or 
not) when building a library function.

Out of interest, what are the errno behaviours of the two versions?

P.

From: Peter Rockett

>My two pennyworth: I would suggest writing your own wrapper around strtod
>following the suggestions at
>http://pubs.opengroup.org/onlinepubs/007904975/functions/strtod.html. 
>"Since
>0 is returned on error and is also a valid return on success, an 
>application
>wishing to check for error situations should set errno to 0, then call
>strtod(), strtof(), or strtold(), then check errno". The wrapper can, of
>course, also check for infinity and nan. That way, you are insulated from
>whether somebody has defined a flag (or not) when building a library
>function.

Having got over the shock of discovering that strtod has changed, I'm now 
thinking I'll just stay with this compiler as is.
Although I prefer "inf" and "nan" strings to be numified to inf and nan 
respectively, I think I can live without it ... and maybe even put the 
changed behaviour to some good use.
And the ramifications for me are not as far reaching as I had first thought.

If, later on, I decide that I must have my preferred behaviour, I'll do it 
then. (Deferring should not mean that additional re-work is involved.)

Thanks for the thoughts/link on how I might fix this.

>Out of interest, what are the errno behaviours of the two versions?

The same - errno remains at zero.

Cheers,
Rob