Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15142 > unrolled thread

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

Started byChet Ramey <chet.ramey@case.edu>
First post2019-07-12 15:25 -0400
Last post2019-07-12 15:25 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: built-in printf %f parameter format depend on LC_NUMERIC Chet Ramey <chet.ramey@case.edu> - 2019-07-12 15:25 -0400

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

FromChet Ramey <chet.ramey@case.edu>
Date2019-07-12 15:25 -0400
SubjectRe: built-in printf %f parameter format depend on LC_NUMERIC
Message-ID<mailman.1048.1562959551.2688.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

On 7/12/19 3:22 PM, Eli Schwartz wrote:
> On 7/12/19 3:16 PM, Chet Ramey wrote:
>> 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.
>>
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html#tag_20_09_16
> 
> "The bc utility always uses the <period> ( '.' ) character to represent
> a radix point, regardless of any decimal-point character specified as
> part of the current locale. 

Good catch. I went by the bc man page that Dennis Williamson posted.

-- 
``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/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web