RE: HUGE is missing in math.h

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Tue, 2005-06-28 at 15:55, Dave Korn wrote:
> ----Original Message----
> >From: Richard Earnshaw
> >Sent: 28 June 2005 15:44
> 
> > On Tue, 2005-06-28 at 15:33, Dave Korn wrote:
> >> ----Original Message----
> >>> From: Richard Earnshaw
> >>> Sent: 28 June 2005 15:26
> >> 
> >>> On Tue, 2005-06-28 at 14:44, Dave Korn wrote:
> >>> 
> >>>>   AFAIUI, IEEE fp is mandated by the ISO C spec, so any system that
> >>>> has a non-IEEE-compliant long double type needs to be using software
> >>>> fp anyway, doesn't it?  Does newlib care about support for
> >>>> non-ISO-C-compliant targets?
> >>> 
> >>> C99 does NOT mandate IEEE fp.  It does, however, have an annex (Annex F)
> >>> that lists a number of features that an IEEE-fp conforming target
> >>> provides.
> >> 
> >> 
> >>   Ah, thanks for the correction.  So, perhaps it would be appropriate to
> >> define these FP constants by bitwise patterns on IEEE compliant targets,
> >> and on non-IEEE targets we use the divide-by-zero patterns and hope for
> >> the best?
> > 
> > You can't even do that.  I should have mentioned this last time, but the
> > problem here is that even a conforming IEEE fp implementation isn't
> > required to use a conforming extended precision type.
> 
>   Sorry, I wasn't being completely clear; I was leaving aside the issue of
> HUGE_VALL at this point, and referring to the others - NAN, INFINITY,
> HUGE_VAL and HUGE_VALF - which I think would be better to hand-craft in
> accordance with the bitwise representations defined in the standard, rather
> than by trying to forcibly generate them with divide-by-zero operations.
> 

I can't say I'm an expert in the details here...

> > So, in fact, you can't even assume that long double will be a strict
> > IEEE type (though it must have infinity and NaNs).
> 
>   Yep.  So perhaps casting INFINITY to long double is our best bet for a
> portable definition of HUGE_VALL?  I suppose I should go take a look at how
> glibc allows for target variations...
> 

It wouldn't surprise me in the least if glibc pulled in headers specific
to each target.  The problem with casting a value from another precision
is that you might end up taking a run-time fault for a non-static use if
optimization was turned off (but the standard only requires these
defines to be 'constant expressions', so it's probably conforming to
allow that).

R.