Date: Sat, 8 Mar 2003 13:11:15 -0800 From: David Schultz <das@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: standards@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: gdtoa import this weekend, future directions Message-ID: <20030308211115.GA66622@HAL9000.homeunix.com> In-Reply-To: <20030308201519.X9873-100000@gamplex.bde.org> References: <20030307063415.GA60214@HAL9000.homeunix.com> <20030308201519.X9873-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Bruce Evans <bde@zeta.org.au>:
> > int strtofi(const char *nptr, char **endptr, float *lo, float *hi);
> > int strtodi(const char *nptr, char **endptr, double *lo, double *hi);
> > int strtoldi(const char *nptr, char **endptr, long double *lo,
> > long double *hi);
> >
> > These routines are like strtod(), but they efficiently compute two
> > floating point numbers that tightly bound the actual value of the
> > parsed string. The vendor implementation returns an integer
> > constant that classifies the number as zero, normal, NaN, etc.
> > Since we already have fpclassify() and a separate set of manifest
> > constants for that, I suggest defining the return value of our
> > version to be zero if the converted value can be represented
> > exactly (in which case 'hi' is also zero) and nonzero otherwise.
> > (I have chosen different function names to reflect that.)
> > Alternatively, we could just add more manifest constants and use
> > the vendor's version. Comments and suggestions are appreciated.
>
> I wouldn't change or reduce gdtoa's interfaces except as necessary
> to prevent references to the parts that we need (mainly strtold()
> and printf/scanf support) dragging in the whole library.
The package contains a few large core routines, principally gdtoa
and strtod, and numerous short wrappers around them that provide
easier to use interfaces. The marginal cost for adding the extras
is small, but I want to make sure that these things are generally
useful and that they fit well with the rest of our math routines.
In addition to the standard strto*, which look at libc's idea of
the rounding direction, there are strtor* versions that take the
rounding direction as an extra argument, and strtoI* versions
(described above) that compute the interval into which the number
falls. All of the nonstandard functions are slightly awkward in
that they return a floating point number by manipulating the
location pointed to by an extra argument that they take; the
return value is as follows:
enum { /* return values from strtodg */
STRTOG_Zero = 0,
STRTOG_Normal = 1,
STRTOG_Denormal = 2,
STRTOG_Infinite = 3,
STRTOG_NaN = 4,
STRTOG_NaNbits = 5,
STRTOG_NoNumber = 6,
STRTOG_Retmask = 7,
/* The following may be or-ed into one of the above values. */
STRTOG_Neg = 0x08,
STRTOG_Inexlo = 0x10,
STRTOG_Inexhi = 0x20,
STRTOG_Inexact = 0x30,
STRTOG_Underflow= 0x40,
STRTOG_Overflow = 0x80
};
I could incorporate the strtoI* and strtor* functions as is, and
stick the above constants in stdlib.h (appropriately ifdef'd, of
course). But then we would have interfaces that convert from
strings to floating point, but not exactly like strtod(), and that
classify floating point numbers, but not exactly like
fpclassify(). The duplication seems a bit kludgy, but I'm
perfectly willing to add the functions either way, since they're
so trivial. I'm not planning to add them immediately, but if
someone has their heart set on any particular interface, please
let me know.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030308211115.GA66622>