From owner-freebsd-standards Sat Mar 8 13:11:28 2003 Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA58A37B404; Sat, 8 Mar 2003 13:11:22 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 428B043FB1; Sat, 8 Mar 2003 13:11:21 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h28LBGLT070240; Sat, 8 Mar 2003 13:11:16 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h28LBFmH070239; Sat, 8 Mar 2003 13:11:15 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Sat, 8 Mar 2003 13:11:15 -0800 From: David Schultz To: Bruce Evans Cc: standards@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: gdtoa import this weekend, future directions Message-ID: <20030308211115.GA66622@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , standards@FreeBSD.ORG, obrien@FreeBSD.ORG References: <20030307063415.GA60214@HAL9000.homeunix.com> <20030308201519.X9873-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030308201519.X9873-100000@gamplex.bde.org> Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Bruce Evans : > > 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