[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A non TZ related question ...

From: Paul Eggert
Subject: Re: A non TZ related question ...
Date: Sun, 27 Jan 2019 02:31:46 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Robert Elz wrote:
That's when the suggestion was made that we should attempt to find
out what other systems do.   Most seem to be like linux (was?) and
only allow '.' (posix actually mandates that for printf

POSIX used to require that for printf, but now it requires the opposite, i.e., POSIX requires printf floating-point operands to be parsed as if by strtod in the current locale. Although this change was apparently made a while ago, I hadn't noticed until now. (POSIX allows programs to accept forms other than what strtod would accept, as extensions, an the escape hatch that my recent change exploits.)

I fixed that by making sleep parse the arg in the user's locale first,
and if that fails, using the C locale (if both fail, it is an error.)

Exactly what I independently did with GNU 'sleep' yesterday. This approach seems better than the alternatives.

Does linux have any utility that would convert numeric
args from one LC_NUMERIC locale to another?

Nothing comes to mind. GNU 'numfmt' would be a good place for that sort of 

double          strtod_l(const char * __restrict, char ** __restrict, locale_t);

glibc already has strtod_l. We haven't found a use for it in GNU utilities, other than as a subroutine of c_strtod. I can see where it might be useful for multilingual and/or multithreaded applications, but so far that hasn't come up.

reply via email to

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