This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
RE: HUGE is missing in math.h
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Ralf Corsepius'" <ralf dot corsepius at rtems dot org>,"'Newlib List'" <newlib at sources dot redhat dot com>
- Date: Tue, 28 Jun 2005 11:25:51 +0100
- Subject: RE: HUGE is missing in math.h
----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
--
Can't think of a witty .sigline today....