Re: [Ask for help]: Met a problem with strtof

[Wang Weidong <wangweidong1 at huawei dot com>]

On 2014/4/25 5:21, Mark Brown wrote:
> On 04/23/2014 08:30 PM, Wang Weidong wrote:
>> I use `gcc -std=c99 -lm test.c -o test` to compile it.
>> then do it `./test`
> 
> Do you see different results when you put the library flag at the end,
> to help the linker resolve things, like:
>    gcc -std=c99 test.c -o test -lm
> 
> That said.....
> 
Hi Mark,

I tried it, but got the same results.

>> I met a problem as below:
>> On SUSE-SP1 x86_64 with glibc-2.11-3 and gcc-4.3.2
>> I got the result:
>>
>> -0x1.4EF009P-16 -> -0x1.4ef00ap-16
>> -0x1.744513P-55 -> -0x1.744514p-55
>> +0x1.1C7509P-19 -> 0x1.1c750ap-19
>>
>> while On Fedora x86_64 with glibc-2.17-19 and gcc-4.8.2
>> I got the result:
>>
>> -0x1.4EF009P-16 -> -0x1.4ef008p-16
>> -0x1.744513P-55 -> -0x1.744512p-55
>> +0x1.1C7509P-19 -> 0x1.1c7508p-19
> 
> gcc did not have a lot of C99 (or IEEE 754) support in it before 4.6;
> also it depends on how well floating point is supported on the hardware
> in question (and the glibc level of course, all software has bugs :-) .
> 
> For what it's worth, I'm seeing results similar to your Fedora output on
> my system (Ubuntu 14.04, gcc 4.9, libc 2.19). My compile line is
>     gcc -std=c99 rounding.c -o rounding -lm
> I have also taken the liberty of adding
>     #pragma STDC FENV_ACCESS ON
> at the start of the file, but I'm unsure if that is really supported in
> gcc (yet).
> 
> 

I add #pragma STDC FENV_ACCESS ON, too. The result is the same.
:-)

I found a Bug report on https://sourceware.org/bugzilla/show_bug.cgi?id=14518
which report "strtod ignores the rounding mode and always tries to round to nearest. "
Such as FE_UPWARD is "rounding towards positive infinity"
It means that the value should "<=" the rounding value.
So I think in glibc-2.11 here "-0x1.4EF009P-16 -> -0x1.4ef00ap-16" it is wrong while
in glibc-2.17+ is right. And similar to the others.

What do you think?

Regards
Wang

>