bug-gnulib
[Top][All Lists]
Advanced

[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}.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]