Date: Sat, 8 May 2004 15:58:38 -0700 From: David Schultz <das@FreeBSD.ORG> To: freebsd-standards@FreeBSD.ORG Subject: Re: Fixing ilogb() Message-ID: <20040508225838.GA15663@VARK.homeunix.com> In-Reply-To: <20040508194748.GN29712@wombat.fafoe.narf.at> References: <20040508194748.GN29712@wombat.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040508225838.GA15663>