RE: HUGE is missing in math.h

["Dave Korn" <dave dot korn at artimi dot com>]

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

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


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....