This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why do we need to fixinclude HUGE_VAL definitions in math.h?


Bruce Korb wrote:
Nathanael Nerode wrote:

fixincludes likes to replace (in math.h)
#define HUGE_VAL blah

with
#ifndef HUGE_VAL
#define HUGE_VAL blah
#endif

I can't figure out *why*, though.  Who's defining HUGE_VAL before math.h
and wants to keep it from being trashed?

(I don't quite know what HUGE_VAL is used for anyway.)


Floating point math.


(This is another one of the tests which I'm trying to straighten out for
OpenBSD fixincludes normalization, because it triggers on OpenBSD, but
isn't changed with the current unusual fixincludes script.)


There are files about that define HUGE_VAL but shouldn't.
So, the fix is to wrap all their definitions in #ifndef.
Since there are multiple broken platforms and since this
transformation is innocuous, ....  It is one of those things
where it would be interesting to know which platforms have
it trigger more than once and suppress it for the rest.  That
is the extent of my recollection.  I pulled it from the
original script.

So if it only triggers once (on math.h, in particular, I suspect :-) then it's innocuous but unnecessary. If it triggers anywhere is, it's necessary.


That makes sense. :-) There must be a reasonable way to say "bypass for math.h".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]