Hi Paul,
Paul Eggert wrote:
> +2010-11-17 Paul Eggert <egg...@cs.ucla.edu>
> +
> + ftoastr: new module, for lossless conversion of floats to short strings
> + * lib/ftoastr.h, lib/ftoastr.c, lib/dtoastr.c, lib/ldtoastr.c:
> + * modules/ftoastr: New files.
Three comments on this:
* The code uses the snprintf() function but the module does not depend on the
'snprintf' or 'snprintf-posix' module. Do you intend to ignore these
portability problems?
This function is missing on some platforms:
IRIX 5.3, OSF/1 4.0, Solaris 2.5.1.
This function overwrites memory even when a size argument <= 1 is passed on
some
platforms:
Linux libc5, 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 behaves incorrectly when a @samp{-} flag and a negative width
are specified together, on some platforms:
HP-UX 10.20.
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.
* This module uses the function strtof(), strtod(), strtold(), which also have
known portability problems. See
doc/posix-functions/strtof.texi
doc/posix-functions/strtod.texi
doc/posix-functions/strtold.texi
In particular, when the gnulib strtod() function is in use, which has known
rounding errors, this will lead to wrong results of the function dtoastr(),
no?
* The URL to the paper that you gave is a closed-content one: it requires
payment. Fortunately, the author of the paper makes it also available online:
<http://florian.loitsch.com/tmp/article.pdf>
His algorithm depends on the existence of a precomputed table of powers of 10
whose size depends on the exponent range. But the 'long double' exponent
range on IA-64 is -16382..16383 (see the IA-64 Architecture Software
Developer's Manual, section 5.1.1), and I can hardly imagine a reasonable
programmer will spend 32766 * 16 bytes = 512 KB on _just_ a table of powers
of 10, even in a shared library. Even for 'double', people may prefer to
allocate a couple of more bits during the precision than to spend
1022 * 8 bytes = 8 KB on a table.
Bruno
