bug-bash
[Top][All Lists]
Advanced

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

Re: built-in printf %f parameter format depend on LC_NUMERIC


From: Chet Ramey
Subject: Re: built-in printf %f parameter format depend on LC_NUMERIC
Date: Fri, 12 Jul 2019 15:16:24 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 7/12/19 12:46 PM, Léa Gris wrote:
> Le 09/07/2019 à 22:02, Chet Ramey écrivait :
> 
>> These are up to the system's strtol/strtod. I don't know of too many
>> strtol implementations that use the thousands separator and numeric
>> grouping.
> 
> Chet and you other Bash maintainers or contributors dudes:
> 
> I can foresee the implications and blockages even lightly considering the
> possibility to align the Bash's built-in printf behavior with the %f
> argument with the sibling GNU Coreutils printf implementation.

I don't think I explained this very well. For input, the printf builtin
relies on strtod(3) to parse the string into a floating point number. For
output, it relies on printf(3) to display a floating point number as a
string. I'm not really interested in re-implementing either one if the
system libc provides one that's perfectly acceptable. On POSIX-conformant
systems, those library functions generally honor the locale's decimal_point
character as the radix character.

The `bc' you're using isn't POSIX conformant.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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