Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Eli Schwartz <eschwartz@archlinux.org>
Newsgroups: gnu.bash.bug
Subject: Re: built-in printf %f parameter format depend on LC_NUMERIC
Date: Fri, 12 Jul 2019 15:22:56 -0400
Lines: 112
Approved: bug-bash@gnu.org
Message-ID: <mailman.1047.1562959397.2688.bug-bash@gnu.org>
References: <5d24be33.1c69fb81.59c43.fe4dSMTPIN_ADDED_BROKEN@mx.google.com> <a212b38c-914d-dda6-8d22-e9039063768e@case.edu> <6468b45e-5b4a-8edf-4ab8-0838843beaaf@noiraude.net> <b6f65b6b-1487-0c46-6530-fa6d700ff1ca@case.edu> <7c757690-24bd-7b1a-cf8e-af63cbe05216@noiraude.net> <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu> <4dde13d8-dc42-52b5-bc15-e5390f6d7ec5@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7f5RdcvoDeaotQuJS28FIFIubsyfiY5AY"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Openpgp: preference=signencrypt
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
In-Reply-To: <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:15141

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7f5RdcvoDeaotQuJS28FIFIubsyfiY5AY
Content-Type: multipart/mixed; boundary="wSj5SOdbbibrDXOjCzkbxUpWTD710OeSx";
 protected-headers="v1"
From: Eli Schwartz <eschwartz@archlinux.org>
To: bug-bash@gnu.org
Message-ID: <4dde13d8-dc42-52b5-bc15-e5390f6d7ec5@archlinux.org>
Subject: Re: built-in printf %f parameter format depend on LC_NUMERIC
References: <5d24be33.1c69fb81.59c43.fe4dSMTPIN_ADDED_BROKEN@mx.google.com>
 <a212b38c-914d-dda6-8d22-e9039063768e@case.edu>
 <6468b45e-5b4a-8edf-4ab8-0838843beaaf@noiraude.net>
 <b6f65b6b-1487-0c46-6530-fa6d700ff1ca@case.edu>
 <7c757690-24bd-7b1a-cf8e-af63cbe05216@noiraude.net>
 <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>
In-Reply-To: <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>

--wSj5SOdbbibrDXOjCzkbxUpWTD710OeSx
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

On 7/12/19 3:16 PM, Chet Ramey wrote:
> On 7/12/19 12:46 PM, L=C3=A9a Gris wrote:
>> Le 09/07/2019 =C3=A0 22:02, Chet Ramey =C3=A9crivait=E2=80=AF:
>>
>>> 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.
>=20
> 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. F=
or
> 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-conforma=
nt
> systems, those library functions generally honor the locale's decimal_p=
oint
> character as the radix character.
>=20
> The `bc' you're using isn't POSIX conformant.
>=20

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.

--=20
Eli Schwartz


--wSj5SOdbbibrDXOjCzkbxUpWTD710OeSx--

--7f5RdcvoDeaotQuJS28FIFIubsyfiY5AY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl0o3hAACgkQhIGKaBmv
SpuZpxAApU5gns2ccdpUN6+y/DsioTxpo+VWrZ2dYmCUSCViHdeOa49/Sf++puPZ
4qTSWzgKXe4sXcjeP8MFCfNHopOV4VxIz0EoYliXJ4AspYZfvfCj9pnhP0iuVksq
0+xBzhpwcer9HXpkVPZrDciLskklVJuvPNaQ+Y9418qulgCt7o+Lgi6pKhdhZJ/E
+n5YMlcLTcIQoDCSJyPkoM5GLXOxTWSISklqWGtyyytiHENOeb8KJY0T0txAbWIq
/PUPeS+kAnBB97ShuepGh+a7wMUUCHDv9sr6YYeiRlpHkYm4w6b3Fbgrkq3qWP58
fpwGpq89Ri4V69H85L6W39IUK3r7qtnd/mF3T4DsK3V57pCFWKcQYpvV0ZXQi6ZA
i+CmVTXF9vmJx50XwKBQGMDrrWlI6oKVW6Vb30msGQ19Hxf27jLcJ+GICOBYFYfS
ipbfdUIjcjIlxFrlWvZxMgcT/9Epzktku9YcyMrMX4HOx7mK/2LlaIyWQ8aS98/7
QZ9XFz+CNU9JY2LwhNym90uKX6Cvn9G5QbTQUNOOVdYSIfqaKeBbfulu0DIgzW72
Cug9EzsugD3jkxUiF/09H3UZuszBMiVjC5ga+v7BzzO8dsnJr+uznbkjg2l8m2DG
wlRiNzHbLJMtTqYo9sdxbnnpn7LGdBrXNOSUUIFUCQwQyGAw0zaJAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXSjeEAAKCRDOsWfvtXIr1t9nD/94lYcj
xye8iLERM7xJkRxET8/kFQqlV7VntIoeP2xVJ6UY3F8kkQfAgbaAU0E4fsq3Jy+G
0ss1/qQE1m8MQcJHrOq+SorrJgF8jFUwXRkU2/znxzssTz9usjHr72JZptaPtXFZ
7fj0NOp5bJ4BuuCme/a2D3TrNuHCFROhOlQCRw6q5lDDPyVXJaYVV0k868b413bS
NSIzc+72vdsh7pD5GtjcG24nxGJQ844FI5+tB+9XHfw7i78YOZa472r8YjioUgxS
Un49YgGpAGMwHTMZrAIy8BS22JaRCL5lMHTRg8TyMbjdCVajgzjilF3qQ+FmhOV1
YVW7MzAW+dxRrkIclRJ+fZpHt/U17z0kK23EdQxv0RL8Ckv9tLE3I8XGvuO8PJ1/
U0kMK8+L0b27aPTvUpdoc1nVXnzicHfMjLLisAEb2WROqz+Vuz8lGh1j56IGeCL5
75E+Q0TtvBmCv5yqsyIzUDlywo+PF3lb9vpFg9VhZUdaND3W5Ol/nhl2mK+vHMBV
VjLWj7zHiFUqfHNIog8BTfMqJD0wMCaB7vyWVkL0vq7EoWrUlEFGG5+/EUcueNW4
I3Cuix1+il6vOnvNy3aD1m3j8vDA27DDIAFy9lsPXJbPovrEZeVMsg7NP0JoadC9
syT7Vq5Wyx0XbkTd/zy+yTdlmHJ2D3bHPUOWrQ==
=43eJ
-----END PGP SIGNATURE-----

--7f5RdcvoDeaotQuJS28FIFIubsyfiY5AY--