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

Groups > gnu.bash.bug > #15144

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

Show all headers | View raw

On 7/12/19 3:25 PM, Chet Ramey wrote:
> 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.
> 

Well the man page for XPG6 bc in Solaris 10 claims :

ENVIRONMENT VARIABLES
      See environ(5) for descriptions of the following environment
      variables  that  affect  the  execution of bc: LANG, LC_ALL,
      LC_CTYPE, LC_MESSAGES, and NLSPATH.


Really?

Looking through "Standards, Environments, and Macros" environ(5) seems
to be bluntly saying :


          Most commands will invoke setlocale(LC_ALL, "") prior to
          any other processing. This allows the command to be used
          with  different  national  conventions  by  setting  the
          appropriate environment variables.

uh huh ...

          LC_NUMERIC

              This category specifies the  decimal  and  thousands
              delimiters.  The  information  corresponding to this
              category is stored in a  database   created  by  the
              localedef()    command.   The   default   C   locale
              corresponds to "." as the decimal delimiter  and  no
              thousands  delimiter.  This  environment variable is
              used by localeconv(3C), printf(3C), and strtod(3C).

yep.

corv $
corv $ LC_ALL=fr_FR.UTF-8 LC_NUMERIC=fr_FR.UTF-8 /usr/xpg6/bin/bc -l
a = 0,1
syntax error on line 1, teletype
a = 0.1
b = 0.11
c = a + b
c
.21

c(c)
.97803091472414824491

corv $

baloney.   :-)

I am going to look at the sources for bc just for the fun of it.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: built-in printf %f parameter format depend on LC_NUMERIC Dennis Clarke <dclarke@blastwave.org> - 2019-07-12 15:46 -0400

csiph-web