Hello Michael, > > You can submit a patch for the function description. > > Attached.
Thanks, I applied the second part of your patch. > I've changed the text to 'as if the locale was "C"' in the patched > version. I didn't apply that part, because the "C" locale behaves differently on different systems: On some systems, its encoding is UTF-8, on others it's only ASCII. > > In the long run, > > however, if this function should be usable in libraries, I see two > > possible approaches: > > - Write a correct strtod() implementation - I mean, without rounding > > errors -, and add a 'char decimal_point' parameter. > > I'm not sure this is possible. According to the paper "How to Read > Floating Point Numbers Accurately" by William D Clinger, it can't be > done using fixed precision arithmetic; this implies that memory would > need to be allocated dynamically, but I don't think strtod is allowed to > fail with ENOMEM. It is correct that perfect decimal to binary conversion requires an amount of memory that is proportional to the absolute value of the exponent, and that requires a malloc(). But strtod is allowed to fail with ENOMEM. See POSIX: <http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03> "Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or ..." > What would be the benefit of allowing decimal_point to be specified, > without supporting multi-byte decimal points or any other locale- > specific behaviour? I don't think multi-byte decimal points exist. All glibc locales, at least, have only '.' or ',' as decimal separator. Regarding locale-dependent digits, or grouping characters, I don't know... > Apart from replacing '.', the code would have to filter characters that > wouldn't be accepted in the C locale, since other locales may interpret > them in an unexpected way. Yes. But this is easy preprocessing, compared to the rest of strtod. > I guess the intended meaning is that it won't accept non-ASCII > characters like locale-specific digits, but I think it's misleading to > refer to "ASCII encoding" in this case. I assumed it meant '.'==46, > '0'==48, etc. For me, it's equivalent. Locale-specific digits (other than the standard ones) don't exist in ASCII or the basic POSIX character set. Yes, ASCII specifies not only a set of characters but also their numeric values, but other encodings (such as EBCDIC) are not in use among the audience of gnulib. Bruno PS: The "tiny change" in the ChangeLog entry only means that you need not do a copyright assignment for this patch. 2009-01-20 Michael Gold <mg...@ncf.ca> (tiny change) * doc/c-strtod.texi: Mention a couple of restrictions. --- doc/c-strtod.texi.orig 2009-01-20 23:25:35.000000000 +0100 +++ doc/c-strtod.texi 2009-01-20 23:25:35.000000000 +0100 @@ -1,6 +1,6 @@ @c Documentation of gnulib module 'c-strtod'. -...@c Copyright (C) 2008 Free Software Foundation, Inc. +...@c Copyright (C) 2008-2009 Free Software Foundation, Inc. @c Permission is granted to copy, distribute and/or modify this document @c under the terms of the GNU Free Documentation License, Version 1.3 or @@ -20,4 +20,9 @@ @end smallexample In particular, only a period @samp{.} is accepted as decimal point, even -when the current locale's notion of decimal point is a comma @samp{,}. +when the current locale's notion of decimal point is a comma @samp{,}, +and no characters outside the basic character set are accepted. + +This function aborts via @code{xalloc_die} if it cannot allocate memory. +On platforms without @code{strtod_l}, it is not safe for use in +multi-threaded applications since it calls @code{setlocale}.
