[comp.std.c] HUGE_VAL and friends

wendyt@pyrps5 (Wendy Thrash) (03/23/89)

Because I have to supply a math.h and float.h that work for three different
floating-point formats on otherwise compatible machines, I'd like very much
to make HUGE_VAL and its friends (DBL_MAX, FLT_EPSILON, etc.) expand as
function calls (to things like __huge_val(), __dbl_max(), etc.)

Questions:
1) Does this violate the letter of the standard?
2) Does this violate the spirit of the standard?
3) Has all this been discussed already, so I'm an idiot for not remembering?

The (Dec. 7 draft) standard allows these things to be general double
expressions, so it's hard to see a violation of the letter of the standard.
The rationale says that "the Committee decided to generalize HUGE_VAL to
a positive double expression, so that it could be expressed as an external
identifier naming a location initialized precisely with the proper bit
pattern."  This makes me wonder whether my calls violate the spirit
of the standard, at least with respect to HUGE_VAL.  It seems, BTW, that an
implementation of HUGE_VAL as an external identifier would allow the user
to redefine it on the fly, for instance
	HUGE_VAL = 42.;
Must I allow this?  (I certainly hope not.)

rbutterworth@watmath.waterloo.edu (Ray Butterworth) (03/23/89)

In article <63653@pyramid.pyramid.com>, wendyt@pyrps5 (Wendy Thrash) writes:
> Because I have to supply a math.h and float.h that work for three different
> floating-point formats on otherwise compatible machines, I'd like very much
> to make HUGE_VAL and its friends (DBL_MAX, FLT_EPSILON, etc.) expand as
> function calls (to things like __huge_val(), __dbl_max(), etc.)

Actually, is there anything in the Standard that says what sort of
value HUGE_VAL must have?  e.g. could an implementation have HUGE_VAL
defined as 1.0?  There doesn't seem to be anything in the Standard
that would disallow this value.  A function that returns this value
to indicate an error (e.g. strtod on overflow) must also set errno,
just as it does when it returns 0.0 to indicate an underflow error.

Given that, is there anything that a conforming program can rely
on for the value of HUGE_VAL (other than it's being non-zero)?