Subject: binary/character floating point conversion
To: None <email@example.com>
From: J.T. Conklin <firstname.lastname@example.org>
Date: 03/02/2005 19:48:28
One of my co-workers plans to use the C++ log4cxx logging library,
which requires wide character strings (std::wstring). I have compared
the relative complexity of adding wide strings to NetBSD with the work
necessary to modify log4cxx to only use narrow strings; adding support
to NetBSD makes the most long term sense.
I've been working on the *wprintf functions (adapted from the narrow
character implementations in libc), since they are prerequisites for
libstdc++'s wide string implementation.
I'm about done except for floating point support, which I deferred
because *printf uses the buffer (of narrow characters) returned by
__dtoa() directly. Now that I'm here, it's probably a good idea to
look at binary/character conversion more generally.
As mentioned in the PRs lib/14168 and lib/18803, our *printf does not
support long double. It also appears to have a problem with thread-
safety (__dtoa() returns a Bigint / char* that is freed the next time
it is called, if one thread is time-sliced out before it is done with
the buffer and another calls *printf with a floating point argument,
it looks like bad things may happen). David M. Gay's gdtoa binary/
character library could be used to fix both problems.
I think the first step would be to integrate the new library and make
the slight modifications to *printf() to use it (adding an explicit
freegdtoa() for thread-safety), and adding long double and *wprintf
support once that's solid. I'll make a patch to do that first, but
have some questions.
* Where the dtoa implementation was combined with strtod.c in a single
file, the full gdtoa library is ~50 files. It probably makes sense
to import it into dist/gdtoa. But in the past (long past), it was
a requirement for libc and the kernel subtrees to be self contained
without vpaths out. What are the current guidelines?
* The gdtoa library contains a lot of non-standard strto* functions
with options for specifying rounding direction, computing intervals,
etc. FreeBSD's integration of gdtoa does not include these, I don't
think we want to include them in libc either. Comments?
* The current __dtoa function is treated as an internal implementation
detail and is not exported. I assume that we want to do the same
for a gdtoa based implementation, and the gdtoa.h header would not
* dtoa's strtod.c was modified with platform specific #define's that
describe the floating point type, etc. The gdtoa library includes
the "arithchk" program which figures it out and generates "arith.h";
Similarly, it includes the "qnan" program which figures out the bit
patterns for quiet NANs. Like gdtoa.h, I think these headers would
be private to libc.
Should we have a single "arith.h", or use arithchk to generate one
header per architecture and check it in libc/arch/<cpu>/arith.h or
libc/arch/<cpu>/gdtoa/arith.h? Likewise for gd_qnan.h?
Thanks for any advice,