Mail Archives: djgpp-workers/1999/08/22/13:36:55
Eli Zaretskii wrote:
>
> Could someone please see if this behavior of GCC 2.95 (is it new?)
> affects the libm functions nan() and nanf()? They use a union of an FP
> and an integer variable to generate a NaN. One symptom of a problem
> would be if ``printf ("%+f", nan());'' prints "-NaN", not "+NaN".
>
> Of course, to see if a problem exists, you would need to build the v2.03
> alpha with GCC 2.95.
I haven't tried it (I haven't got GCC 2.95 installed yet) but I think
our code is safe. AFAIK, punning via a union is the correct ANSI way to
access memory as two different types. What isn't allowed is accessing a
given address through pointers of different types.
It might be a good idea to run this by comp.lang.c, where there are
surely people who know all the picky details.
And yes, it is new. It was implemented in earlier versions of EGCS, but
one had to use an option (-fstrict-aliasing) to enable it.
<rant>
How could those EGCS/GCC $@#%$s change the default behavior to break so
much extant code, without even making the compiler warn about the broken
code? They did say it was hard, but IMAO they shouldn't have changed
the default until they got it.
</rant>
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -