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)?