Control: tags -1 + upstream patch Thanks for the analysis.
Checking the current state on ksh93u+m (1.0.10-5), the original arithmetic syntax error is gone, and a '.' literal in a comma-radix locale produces an explicit message: + ksh -c 'echo $((1./2))' + LC_ALL=C 0.5 + ksh -c 'echo $((1./2))' + LC_ALL=de_DE.UTF-8 ksh: 1./2: radix point '.' requires LC_NUMERIC=C + ksh -c 'echo $((1,0/2,0))' + LC_ALL=de_DE.UTF-8 0,5 + ksh -c 'echo $((1./2))' + LANG=de_DE.UTF-8 + LC_NUMERIC=C 0.5 + ksh -c 'echo $((Inf))' + LC_ALL=tr_TR.UTF-8 inf + ksh -c 'echo $((inf))' + LC_ALL=tr_TR.UTF-8 inf + ksh -c 'echo $((ınf))' + LC_ALL=tr_TR.UTF-8 0 The locale-dependent radix point is intentional and is covered by the test suite. The workaround is LC_NUMERIC=C. On the Turkish Inf/NaN point, that recognition happens through ASCII and is not dependent on LC_NUMERIC and so 'ınf' is not matched by design. What remains however is a valid documentation gap for which this patch will be forwarded upstream: --- a/src/cmd/ksh93/sh.1 +++ b/src/cmd/ksh93/sh.1 @@ -3252,8 +3252,13 @@ double precision floating point arithmetic or long double precision floating point for systems that provide this data type. Floating point constants follow the ANSI C programming language -floating point conventions. -The case-insensitive floating point constants +floating point conventions, except that the radix point character +is determined by the +.SM LC_NUMERIC +locale category; set +.B LC_NUMERIC=C +to use a period. +The ASCII case-insensitive floating point constants .B NaN and .B Inf Anuradha
