option to have locale-independent floating-point constants

[vinc17fr]

Contrary to usual programming languages and zsh, floating-point constants in ksh93 depend on the locale for the decimal delimiter (decimal-point character), which is unpractical and surprises users. For instance, the commands

ksh93 -c 'echo $((1./2))'
ksh93 -c 'printf "%g\n" 0.5'

output an error in locales where the decimal delimiter is not the period. This also affects the comma operator when the decimal-point character is the comma:

$ for s in "1,2" "1, 2" " 1 ,2" "1 , 2" ; do LC_ALL=fr_FR.utf8 ksh93 -c "echo \$(( $s ))" ; done
1,2
ksh93:  1, 2 : arithmetic syntax error
ksh93:   1 ,2 : arithmetic syntax error
2

while mksh and bash output 2 in these 4 cases.

Note that printf from the GNU Coreutils accepts both the period and the decimal-point character of the current locale (when different), like GNU MPFR's mpfr_strtofr function. Perhaps this should also be the case for ksh93.

There should be an option to have locale-independent floating-point constants:

• in arithmetic expressions (and only accept the period as the decimal-point character to avoid the issue with the comma operator);
• with the printf builtin (possibly accept both the period and the decimal-point character of the current locale, like with GNU Coreutils, and possibly even without such an option).

Also note that in the ksh93(1) man page (ksh93u+m 1.0.10-5 Debian package):

• "Floating point constants follow the ANSI C programming language floating point conventions." This is not correct since C floating-point constants do not depend on the current locale.
• "It is a good idea to leave a space after the comma operator in arithmetic expressions to prevent the comma from being interpreted as the decimal-point character in certain locales." But a space before the comma operator may also be needed as shown above.

For the reference: #145

[vinc17fr]

Note also that there is an inconsistency in POSIX concerning the printf utility with the a, A, e, E, f, F, g, G conversion specifiers and what is said about LC_NUMERIC. See the report I've just done: inconsistency about the printf utility concerning LC_NUMERIC. I'm not sure that they have thought about the locale issue for the input when specifying the printf utility.

[McDutchie]

This issue is a duplicate of #145, which it seems you had already discovered. It was discussed back then and decided it's not going to change.

The documentation issue has been fixed in #1002, thanks to @aweeraman.

Note that mksh has no printf built-in command at all, so whenever you're testing mksh, you're testing the external printf command on your system.

Note that printf from the GNU Coreutils accepts both the period and the decimal-point character of the current locale (when different)

However, /usr/bin/printf on macOS, *BSD, Solaris, and illumos only accepts the radix point for the current locale (either . or , but never both). GNU is the outlier here.

There should be an option to have locale-independent floating-point constants:

Such an option would have to be turned on proactively, in which case you might as well set LC_NUMERIC to the desired locale instead. So I don't really see the added value there.