RE: HUGE is missing in math.h

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

Pardon my innocence, but I believe C99 introduced floating point hex
constants precisely for this purpose.

Regards,

Konrad

> -----Original Message-----
> From: newlib-owner@sources.redhat.com 
> [mailto:newlib-owner@sources.redhat.com] On Behalf Of Tim Prince
> Sent: Tuesday, June 28, 2005 2:36 PM
> To: Dave Korn
> Cc: 'Ralf Corsepius'; 'Newlib List'
> Subject: Re: HUGE is missing in math.h
> 
> 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."
>