[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: c-strtod threading and documentation problems
From: |
Bruno Haible |
Subject: |
Re: c-strtod threading and documentation problems |
Date: |
Tue, 20 Jan 2009 23:26:49 +0100 |
User-agent: |
KMail/1.9.9 |
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 <address@hidden> (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'.
address@hidden Copyright (C) 2008 Free Software Foundation, Inc.
address@hidden 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}.