While struggling with Solaris and a native Pike compilation, I stumble across some interesting wildlife regarding the definitions (or lack thereof) of +Inf, -Inf and NaN in Pike.
Some points of interest are: - On occasion there seems to be a dependency on HUGE_VAL which is undesirable. - Configure is trying to figure out the way floats are stored (big/little endian, IEEE format or not). - In the IEEE case, we hardwire Inf and NaN through their bytewise representation in a union. - In the non-IEEE case we resort to the usage of infnan or HUGE_VAL.
I'm just wondering, instead of this plethora of different avenues (some more convoluted and undesirable than others), is there a compelling reason not to define the following two macros as:
#define MAKE_INF(s) (DBL_MAX*DBL_MAX*(s)) #define MAKE_NAN() (0.0/0.0)
The upside is that DBL_MAX is defined by ANSI C in <float.h> and is bound to be present on all relevant systems.
The only reason I could imagine that defining the above macros could pose a problem is with very old C-compilers on systems that generate a runtime error on either of the above two expressions. Then again, in that case you might be better off running older versions of Pike anyway.
That they may cause runtime (or compile time) errors on some compilers is reason enough not to use them except as a last resort. Any function provided by the libc to generate these values is better than an expression which we can merely hope produce the desired value (and which can crash the pike process on startup otherwise). If you know of any more such functions in addition to the ones we already support, feel free to add them.
As for the hardwired IEEE variants, we need to check for IEEE format anyway, since %F gets optimized if we have it (which is usually the case), so why not use the result to get something which is bound to work on such systems?
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Stephen R. van den Berg