X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Martin Stromberg <Martin DOT Stromberg AT epl DOT ericsson DOT se>
Message-Id: <200304221232.OAA06267@lws256.lu.erisoft.se>
Subject: Re: Yet another try on nan in strto{f,d,ld}
To: djgpp-workers AT delorie DOT com
Date: Tue, 22 Apr 2003 14:32:06 +0200 (MET DST)
In-Reply-To: <968-Tue22Apr2003144023+0300-eliz@elta.co.il> from "Eli Zaretskii" at Apr 22, 2003 02:40:23 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

Eli said:
> > 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.

Ok. But do you see that it's two different paragraphs describing
different cases of input? It's not redundant, IMHO.

> > > 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);

This shouldn't be influenced by restrict at all. restrict is applied
to input parameters of functions.

Is there another use of restrict that I'm not aware of?

> Btw, is code such as this:
> 
>      double tmp_d = NAN;
> 
> safe when numerical exceptions are unmasked in the FP control word?

No idea.

> 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?

NAN is a QNaN (of type float), so it shouldn't. I think that it
remains that even when we assign it to double and long double
variables.

> > 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?

No. But I need to know to implement it right, don't I? (For me,
logically, any Unnormal may well be a NaN as it's obviously not a
number...)


Right,

						MartinS