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: Sun, 18 Jan 2009 03:42:29 +0100
User-agent: KMail/1.9.9

Hi,

Michael Gold wrote:
> I was planning to use the c-strtod module in a library, but noticed some
> problems when looking at its implementation.
> ...
> This is
> not threadsafe because setlocale affects all threads in a program (and
> also because setlocale doesn't seem to be threadsafe on all platforms).
> The attached program demonstrates the problem -- if some thread calls
> strtod while another is calling c_strtod, the call to strtod may return
> an incorrect result in locales where the decimal point isn't '.'.
> 
> c_strtod will also call abort() on these platforms if there's no memory
> to copy the old locale string, which makes it inappropriate for use in
> libraries. This should be documented in the function description.

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.

You can submit a patch for the function description. 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.
  - Copy the argument string, preprocessing it by replacing the '.'
    with the locale dependent decimal-point character, and pass that
    to strtod().

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

> The first problem could probably be fixed by calling localeconv and
> replacing '.' with the proper decimal point, which may require a
> temporary memory allocation.

Yes, nearly. Note that localeconv() is not multithread-safe either. Instead,
we could use the function decimal_point_char() from lib/vasnprintf.c.

Bruno




reply via email to

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