Re: strtod ("nan") returns negative NaN

Craig Howland <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On 08/15/2018 11:40 AM, Joseph Myers wrote:
> On Wed, 15 Aug 2018, Joseph Myers wrote:
>
>> On Tue, 14 Aug 2018, Craig Howland wrote:
>>
>>>       The f_QNAN value should be 0x7fc00000 regardless of byte ordering.  In
>> It would be better to use __builtin_nan ("") (and __builtin_nanf,
>> __builtin_nanl for other types) rather than using an integer
>> representation at all (of course that requires changes to other code to
>> avoid requiring an integer representation there).
I totally agree.  To add it to the record, in conjunction with this, the strtod 
implementation really should be upgraded to David Gay's more recent version, 
which is 128-bit friendly.  (I almost had this done some time ago, but didn't 
quite finish.)
> (This is not an objection to any of the present patch proposals, just an
> observation that a different approach would avoid a series of problems
> that result from trying to hardcode information about such choices of
> bit-patterns for NaNs.)
>
Also agreed.  If I had had time yesterday I might have tried it as I had briefly 
thought of it, but didn't think to get the idea out to the list, so I'm glad you 
did.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.