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

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

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

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 Eli Schwartz <eschwartz@archlinux.org> - 2019-07-12 15:22 -0400

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

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

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. In languages like C or awk, the <period>
character is used in program source, so it can be portable and
unambiguous, while the locale-specific character is used in input and
output. Because there is no distinction between source and input in bc,
this arrangement would not be possible. Using the locale-specific
character in bc's input would introduce ambiguities into the language;
consider the following example in a locale with a <comma> as the
decimal-point character:"

Seems like POSIX explicitly defines that the bc utility is granted an
exception here. So it is, in fact, POSIX-conformant to what bc is
supposed to do -- it is just that POSIX bc requires additional handling
in order for its input/output to interoperate with other utilities.

-- 
Eli Schwartz

[toc] | [standalone]

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

csiph-web