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
  be installed?

* 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, 

    --jtc

-- 
J.T. Conklin