On Wed, Jan 21, 2009 at 12:39:50 +0100, Bruno Haible wrote:
> 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'.
Actually, C99 states 'In ot
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 a
On Tue, Jan 20, 2009 at 23:26:49 +0100, Bruno Haible wrote:
> 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:
T
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 differe
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 (includin
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 p
