Re: Command line arguments depend on locale

[Eric Blake]

On 01/31/2013 11:25 AM, Pádraig Brady wrote:
> A less clear cut example is printf(1).
> POSIX states that LC_NUMERIC controls the format
> of the numbers _written_.
> In coreutils we're careful to reset to the C locale
> so that strtod etc. work consistently.

POSIX says that in non-C locales, strtod() is free to parse additional
formats; resetting to the C locale limits what can be parsed, at the
expense of avoiding confusion over how to parse the decimal separator.

> 
> Just testing bash here shows it was a different interpretation
> which I would deem not what POSIX intended:
> 
> # coreutils
> $ LC_NUMERIC=de_DE env printf "%f\n" 0.1
> 0,100000

Unfortunately, here, you have a problem.  POSIX says that printf(1) need
not support "%f", so you are already on unspecified grounds, and there
is no clear case as to whether the input is to be parsed according to
the output locale or according to the C locale.  This may be worth
raising with the Austin Group.

> $ LC_NUMERIC=de_DE env printf "%f\n" 0,1
> printf: 0,1: value not completely converted
> 0,000000
> 
> # bash
> $ LC_NUMERIC=de_DE printf "%f\n" 0,1
> 0,100000
> $ LC_NUMERIC=de_DE printf "%f\n" 0.1
> bash: printf: 0.1: invalid number
> 0,000000
> 

It would be nice if we had strtod_l and printf_l for finer control of
which locale is used during parsing and output; and that having a
well-specified manner for specifing orthogonal locales for
transliterating floating point from one representation to another seems
like a missing feature in POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature