HUGE is missing in math.h

[Tim Prince]

Dave Korn wrote:

>----Original Message----
>  
>
>>From: Ralf Corsepius
>>Sent: 28 June 2005 10:19
>>    
>>
>
>  
>
>>On Tue, 2005-06-28 at 09:52 +0200, Corinna Vinschen wrote:
>>    
>>
>>>On Jun 27 17:25, Jeff Johnston wrote:
>>>      
>>>
>>>>Corinna Vinschen wrote:
>>>>        
>>>>
>>>>>However, other definitions are missing in math.h, like HUGE_VALF,
>>>>>HUGE_VALL, INFINITY and NAN.
>>>>>          
>>>>>
>>>>I'll take a look at adding these unless you want to.  HUGE_VALL is the
>>>>only one that is difficult.
>>>>        
>>>>
>>>Would it be a problem to use the Mingw definitions?
>>>
>>>  #define NAN (0.0F/0.0F)
>>>  #define HUGE_VALF (1.0F/0.0F)
>>>  #define HUGE_VALL (1.0L/0.0L)
>>>  #define INFINITY (1.0F/0.0F)
>>>      
>>>
>>Are you sure none of these "divisions by zero" doesn't result into an
>>exception on some architectures?
>>
>>Ralf
>>    
>>
>
>
>  And, indeed, might whether it did or not vary according to whether you
>compile with optimisations on or off, and which compiler you are using,
>because it might be evaulated at either run- or compile-time?  And then it
>might vary according to whether you were using a cross-compiler or not?
>
>  I don't have a copy of the 754 standard, but IIRC it clearly defines the
>representations of (at least some of) these various constants in terms of
>bit-patterns in the various fields (s/e/m) of the fp type, and shouldn't we
>just implement those as hex constants of the appropriate target-dependent
>endian-ness, which should be a thoroughly cross-platform solution?  (I'll
>see if I can find a copy of the standard online anywhere to study.)
>
>    cheers,
>      DaveK
>  
>
64-bit, 80-bit and 128-bit long long are supported in common 
IEEE-compliant compilers, and there are quite a few machines with a long 
long which is not IEEE-compliant.  If newlib is restricted to just one 
of those categories, it doesn't look like "a thoroughly cross-platform 
solution."