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: Wed, 21 Jan 2009 12:39:50 +0100
User-agent: KMail/1.9.9

Hi Michael,

> fa_IR has a multi-byte monetary decimal point in glibc, but the regular
> ones are all "." or ",".

Yes. The monetary decimal point matters for strfmon(), but not for strtod().

> That locale also prints in Arabic-Indic 
> numerals if you use the "I" printf flag, but these numerals are rejected
> by strtod.

Yes. While the strtod specification explains the locale dependency of the
decimal point, it does not do so for the digits; hence it's safe to assume
that the digits understood by strtod are only '0'..'9'.

> strtod also rejects decimal separators, at least in da_DK (which prints
> them when the "'" flag is specified), so maybe these features aren't
> important.

Indeed. The strtod specification assumes a sequence of digits without
grouping characters.

> Do you want me to submit a patch that does this preprocessing? I guess
> decimal_point_char would need to go into a new module if localeconv
> isn't safe to use

Yes, this would be welcome: it would allow c_strtod to be multithread-safe.

Do you already have copyright assignments with the FSF in place, for your
gnulib contributions? If not, then now is the right time to start the
process (request the forms from the FSF, sign them and snail mail them back).

> (and human.c would need to use it too). 

human.c does not need to become multithread-safe as urgently, IMO.

> But could localeconv really cause a problem? Since it's not safe to
> change locales in a multi-threaded application, I don't see what the
> problem would be.

The problem is that some systems have functions for changing the locale
of the current thread (uselocale()). What happens when multiple threads
call localeconv simultaneously? The localeconv() implementation may
return a pointer to a static buffer; it is not required to return a copy
in thread-local storage or in memory allocated for each locale. Quoting
<http://www.opengroup.org/onlinepubs/9699919799/functions/localeconv.html>:
  "The localeconv() function need not be thread-safe."

> OK. I assumed non-ASCII encodings were supported because c-ctype.c seems
> to go out of its way to support them (and has the same comment about
> encoding in its documentation as c-strtod).

Yes, in some places we assume ASCII, in others we don't. When possible,
we prefer not to hardcode ASCII values.

Bruno




reply via email to

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