Mail Archives: djgpp-workers/2000/03/20/12:17:56
Eli Zaretskii wrote:
> > sscanf(xys[i], "%lli", &nd);
> > }
> > x[i] = *((double *) &nd);
>
> Beware of this last line: latest versions of GCC could do various tricks
> with it, which makes loading literal infinities and nans not trivial.
That's why I called the program "hacky". ;-) In 2.9.5.2, -fno-strict-aliasing is
still enabled by default, which allows this hack to work, and resolve the immediate
question, which is all the code was intended to do. The gcc docs say that unions
will work for this "type-punning", even with -fstrict-aliasing, but I don't think
even that's standard C.
> > On my Pentium II, I found that -NaN = -NaN * -NaN; all other sign
> > combinations produced +NaN.
>
> This contradicts the Intel manual. (So what else is new?)
I have been poring over the Intel manuals and cannot find anything about the sign
of a product of NaNs. Where did you find the information?
> > 220When applied to infinite and NaN values, the -, +, and
> > space flag characters have their usual meaning; the # and
> > 0 flag characters have no effect.
> >
> > it seems that "real indefinite" must be printed out as negative.
>
> Hmm? How do you see it from this footnote? IIRC it refers to the - and
> + flags in the format specifier, which we do support.
I'm not arguing that real indefinite should be printed out as -nan in the absence
of a + in the format specifier, but my argument, in part, is that the standard is
sufficiently muddled on that point that we have to make up our own minds. I agree
that the footnote doesn't refer to the case where the "+" is absent in the format
specifier, but it is evidence that the standard is unclear on the interpretation of
the sign bit for NaNs.
-Eric Rudd
- Raw text -