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: Michael Gold
Subject: Re: c-strtod threading and documentation problems
Date: Mon, 19 Jan 2009 23:59:22 -0500
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jan 18, 2009 at 03:42:29 +0100, Bruno Haible wrote:
> The module 'c-strtod' is under GPL, not LGPL. This alone is enough of a
> hint that the function is not really usable in libraries.

I don't agree that this is a good enough hint, since some libraries are
licensed under the GPL (including GNU PDF, which I was referring to).

> You can submit a patch for the function description.

Attached.

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

What would be the benefit of allowing decimal_point to be specified,
without supporting multi-byte decimal points or any other locale-
specific behaviour?

>   - Copy the argument string, preprocessing it by replacing the '.'
>     with the locale dependent decimal-point character, and pass that
>     to strtod().

Again, this wouldn't be an exact replacement for strtod since it could
fail with ENOMEM (or by aborting), but that's probably fine if it's
documented. Even the code path that calls strtod_l might fail with
ENOMEM if newlocale calls malloc (although glibc doesn't allocate memory
when accessing the "C" locale).

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. Replacing them with '\0' would probably work.

> > Finally, the documentation states c_strtod "operates as if the locale
> > encoding was ASCII", but the code doesn't actually convert the argument
> > from ASCII to the execution character set.
> 
> We assume that the execution character set is a superset of the part of
> ASCII that matters for numbers (digits, basic Latin letters, dot, comma,
> plus, minus signs).

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.

I've changed the text to 'as if the locale was "C"' in the patched
version.

-- Michael

Attachment: gnulib-c_strtod-doc.diff
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

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