Re: [PATCH] ftoastr: new module, for lossless conversion of floats to short strings

[Bruno Haible]

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