Hi Paul,
> * lib/ftoastr.c: Also mention Loitsch's draft.
Thanks.
> * lib/ftoastr.h: Require WIDTH to be nonnegative. This isn't
> needed in the current implementation, but it might simplify
> speeding up the code later.
It also avoids the bug with '-' flag and negative width on HP-UX 10.20.
> On the
> one hand, I want ftoastr to work portably. On the other, I also want
> it to work for packages that want to assume a working snprintf and
> don't want to drag in that other stuff.
Such packages can pass --avoid=snprintf --avoid=snprintf-posix to
gnulib-tool. They then assume the responsibility for the portability
bugs into which they will run.
> It'd be nice for ftoastr to use snprintf if it works, and use sprintf
> otherwise.
This wouldn't bring a lot of safety, because the majority portability bugs
of snprintf is also present in sprintf. (See the matrix at the end of
m4/printf.m4.)
> * modules/ftoastr: Depend on snprintf; this improves portability.
Still, ftoastr is likely affected by the following portability problems
mentioned in doc/posix-functions/snprintf.texi:
This function overwrites memory even when a size argument <= 1 is passed on
some
platforms:
BeOS, OSF/1 5.1.
printf of @samp{long double} numbers is unsupported on some platforms:
mingw, BeOS.
printf @code{"%g"} of Infinity and NaN yields an incorrect result on some
platforms:
AIX 5.2, OSF/1 5.1, Solaris 10, mingw.
This function does not support precisions larger than 512 or 1024 in integer,
floating-point and pointer output on some platforms:
mingw, BeOS.
This function can crash in out-of-memory conditions on some platforms:
MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0.
This function does not truncate the result as specified in C99 on some
platforms:
mingw.
This function does not return a byte count as specified in C99 on some
platforms:
HP-UX 11, IRIX 6.5, OSF/1 5.1, mingw.
I can see two ways of fixing it:
a) Require 'snprintf-posix' instead of 'snprintf'. Or
b) Write a test suite that checks against the effects of these bugs and add
corresponding workarounds to lib/ftoastr.c. But adding printing of
'long double' numbers (which you need for ldtoastr()) isn't done in 100
lines of code...
> Is there an easy way for code to ask whether snprintf is available in
> the presence of gnulib modules, regardless of whether it's builtin or
> supplied by gnulib? I'd like something like this
>
> #if HAVE_SNPRINTF
> (use snprintf)
> #else
> (use sprintf)
> #fi
>
> except it's not obvious from stdio.in.h what #if test to use here.
You would have to add a line
gl_MODULE_INDICATOR([snprintf])
to the snprintf module, and then test
#if HAVE_SNPRINTF || GNULIB_SNPRINTF
Bruno
