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
