On 8/19/21 9:41 AM, Léa Gris wrote: > Le 19/08/2021 à 15:10, hancooper écrivait : >> Thusly, EPOCHREALTIME should not be made to depend on the locale. I >> have seen many >> workarounds, that complicate rather than simplify something that >> should be straighforward >> and germaine to direct numeric computation. > > A agree 100% > > It is as frustrating as printf arguments format being dependent on > locale settings: > > This will fail because of questionable design decision of having a > mutable argument format: > > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')" > > Note how the format indicator still use a dot, but the argument format's > decimal separator is that of the system's locale. > > Imagine if C++ or Java had methods with different signature depending on > system locale. You would scream fool. But for Bash, it was decided it > was all fine.
Bash printf behaves the same as C here (format indicator and all).
But without typed arguments it needs to parse the string
"3.14159265358979323844" into a float, because everything is a string
and thus doesn't have different signatures ever.
The error occurs, one would imagine, during the "convert string to
float" stage, after parsing argv or forking to bc or whatever, but
*before* passing it as an argument to printf(3). Here, bash is just
doing good error checking -- if you used
strtof("3.14159265358979323844", NULL) under a fr_FR.UTF-8 locale, it
would silently drop everything after the ".", and you would
"successfully" print 3,0000, but bash reports an error message.
Locales define output formatting for display, not source code formatting
for machine translation. Your entire problem, from beginning to end, has
nothing whatsoever to do with signatures, and everything to do with a
lack of types.
bc doesn't communicate a float-typed value to printf, but it also
doesn't respect LC_NUMERIC (for the reasons specified in the POSIX
description under "Application Usage").
On the other hand, printing the output of bc into a C source file and
compiling it, rather than interpreting it via strtof, would cause it to
be parsed as machine-formatted, not display-formatted, and hence the
LC_NUMERIC separator would not skew the results.
For a C program, because C has types and bash does not.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
OpenPGP_signature
Description: OpenPGP digital signature
