Mail Archives: djgpp-workers/2003/04/22/08:32:24
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
- Raw text -