Date: Tue, 22 Apr 2003 14:40:23 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <968-Tue22Apr2003144023+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <200304220902.LAA06094@lws256.lu.erisoft.se> (message from Martin
	Stromberg on Tue, 22 Apr 2003 11:02:14 +0200 (MET DST))
Subject: Re: Yet another try on nan in strto{f,d,ld}
References:  <200304220902 DOT LAA06094 AT lws256 DOT lu DOT erisoft DOT se>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Martin Stromberg <Martin DOT Stromberg AT epl DOT ericsson DOT se>
> Date: Tue, 22 Apr 2003 11:02:14 +0200 (MET DST)
> 
> Eli said:
> > > From: <ams AT ludd DOT luth DOT se>
> > > Date: Sun, 20 Apr 2003 20:04:40 +0200 (CEST)
> > A minor nit: you say twice that the ``-'' causes the sign bit of a NaN
> > to be set.
> 
> I do? Please post quote both. (I can't find what you mean.)

Here's the relevant hunk of one of the diffs where this happens:

    -The value the represented by @var{s}.
    +The value represented by @var{s}.
    +
    +If @var{s} is ``Inf'' or ``Infinity'', with any variations of
    +case and optionally prefixed with ``+'' or ``-'', the return value is
    +@code{INFINITY} (if no prefix or a ``+'' prefix) or @code{-INFINITY}
    +(if the prefix is ``-'').
    +
    +If @var{s} is ``NaN'' or ``NaN()'', with any variations of case
    +and optionally prefixed with ``+'' or ``-'', the return value is
>>> +@code{(double)NAN}.  If the prefix is ``-'' the sign bit in the NaN
>>> +will be set to 1.
    +
    +If @var{s} is ``NaN(@var{hex-number})'', with any variations of
    +case and optionally prefixed with ``+'' or ``-'', the return value is
    +a NaN with the mantissa bits set to
    +@code{@var{hex-number}&0xfffffffffffff} (the mantissa for doubles
    +consists of 52 bits).  Use at most 16 hexadecimal digits in
    +@var{hex-number} or the internal conversion will overflow, which
    +results in a mantissa of 0xfffffffffffff.  If
    +@code{@var{hex-number}&0xfffffffffffff} is 0 (which won't work as a
>>> +representation of a NaN) @code{(double)NAN} will be returned.  If the
>>> +prefix is ``-'' the sign bit in the NaN will be set to 1.  Testing
    +shows that SNaNs might be converted into QNaNs (most significant bit
    +will be set in the mantissa).

Note the lines marked with ">>>" on the left.

> > Also, I'm a bit worried by the typecast juggling you do: won't that
> > get in our way when/if we want to add ``restrict'' qualifiers to the
> > library sources and headers?
> 
> Do you mean "unconst" or "return *(double *)(&n)"? Or something else?

I mean the plain typecasts, like this:

    +    double_t n = *(double_t *)(&tmp_d);

or this:

    +	return *(double *)(&n);

Btw, is code such as this:

     double tmp_d = NAN;

safe when numerical exceptions are unmasked in the FP control word?
That is, won't that line by itself produce a SIGFPE in that case, and
if it does, is that okay, as far as C9x and our common sense are
concerned?

> We need to decide if the integer bit influences the NaNess of a long
> double for strtold().

I think it should.  I think if that bit is unset, the result should
not be a NaN.  Is it a problem to implement strtold this way?