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: "'Richard Earnshaw'" <rearnsha at gcc dot gnu dot org>
- Cc: <tprince at computer dot org>,"'Ralf Corsepius'" <ralf dot corsepius at rtems dot org>,"'Newlib List'" <newlib at sources dot redhat dot com>
- Date: Tue, 28 Jun 2005 17:01:09 +0100
- Subject: RE: HUGE is missing in math.h
----Original Message----
>From: Richard Earnshaw
>Sent: 28 June 2005 16:32
> 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
That's the exact same problem that I'm worried about happening if we try
tricks like
#define INFINITY (1.0F/0.0F)
which is why I'm keen on hand-crafting the correct bitwise representation of
an INF.
> (but the standard only requires these
> defines to be 'constant expressions', so it's probably conforming to
> allow that).
Hmmm. I need some more head-scratching time on this one. The standard
certainly allows that, but presumably it also require the behaviour to be
the same regardless of whether we evaluate the expression at runtime or at
compiletime? We may be introducing dependencies on the inner details of
compiler behaviour if we're not careful here. Is glibc allowed to assume
that it's being compiled by gcc / running with gcc-compiled code?
cheers,
DaveK
--
Can't think of a witty .sigline today....