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: Tue, 20 Jan 2009 23:14:02 -0500
User-agent: Mutt/1.5.18 (2008-05-17)

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:

Thanks, that makes things easier.

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

fa_IR has a multi-byte monetary decimal point in glibc, but the regular
ones are all "." or ",". That locale also prints in Arabic-Indic
numerals if you use the "I" printf flag, but these numerals are rejected
by strtod.

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.

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

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 (and human.c would need to use it too).

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.

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

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

-- Michael

Attachment: signature.asc
Description: Digital signature


reply via email to

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