Fixing ilogb()

[David Schultz]

On Sat, May 08, 2004, Stefan Farfeleder wrote:
> I found two problems with our current ilogb() implemenation(s).
> 
> - Both the man page and FP_ILOGB0 claim that ilogb(0) returns INT_MIN
>   while the implementation in s_ilogb.c returns -INT_MAX.  We really
>   have to decide on one value (both are conforming to C99, I've attached
>   the text).  The attached patch assumes that -INT_MAX is kept.

FWIW, SunOS has historically used the following mapping:

	ilogb(0)        ==> -INT_MAX
	ilogb(NAN)      ==> INT_MAX
	ilogb(INFINITY) ==> INT_MAX

This matches OS X, our MI ilogb() implementation[1], and your
patch, and I think those are pretty good reasons to use your
version.

>   On a related note, is there a reason why <math.h> doesn't use
>   <machine/_limit.h>'s __INT_M{AX,IN} for the FP_ILOGB* macros?

Yes, machine/_limits.h did not exist when it was written, so there
was no way to get INT_{MIN,MAX} without namespace pollution.
It would be a good idea to use these in math.h and s_ilogb[f].c now.

> - On i386 the assembler file s_ilogb.S is used instead.  It uses the
>   instruction fxtract which returns INT_MIN for 0, infinity and NaN.
>   Except for infinity this conforms too, but doesn't play well with our
>   MI definitions for FP_ILOGB*.  In the attached patch I've aligned
>   s_ilogb.S's behaviour with s_ilogb.c, the alternative would be just
>   fixing infinity and making FP_ILOGB* MD.

Although it would be legitimate to make FP_ILOGB* MD, we have to
fix the infinity case anyway, so we might as well make the NAN and
0 cases MI.

FWIW, I was working on some faster MD implementations of
fpclassify() and friends a while ago, and getting these corner
cases to be consistent is a big PITA.  ;-)

[1] This is unsurprising, given its origin.