Force the use of '.' as decimal separator.

[xdch47]

This solves issues occuring with a different decimal operator and
keeps the commandline interface consistent for all locales .
E.g. zfs set quota=0.5T

Signed-off-by: Felix Neumärker xdch47@posteo.de

Motivation and Context

Description

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[xdch47]

Explanation:

Comparision to a decimal point as '.' takes place and strtod(...) follows, e.g.

zfs/lib/libzfs/libzfs_util.c

Line 1553 in 6fffc88

if (*end == '.') {

or assumptions are made:

zfs/module/zcommon/zfs_prop.c

Line 749 in 6fffc88

c == '-' || c == '_' || c == '.' || c == ':');

zfs/lib/libzfs/libzfs_util.c

Line 1527 in 6fffc88

if ((value[0] < '0' || value[0] > '9') && value[0] != '.') {

zfs/include/sys/lua/luaconf.h

Line 551 in 6fffc88

#define getlocaledecpoint() ('.')

[gdevenyi]

Rather than forcing a decimal point, shouldn't those comparisons be properly localized?

[xdch47]

Small impacts are the print-out (%f format).
Another option would be to use struct lconv as described here.

[xdch47]

Rather than forcing a decimal point, shouldn't those comparisons be properly localized?

would be an option as well, but make everything more difficult to maintain and also changes the command input depending on locale.

imo it would feel odd to use zfs set quota=0,5T and might collide with , as list separator

-- shell tools are handling that different [zsh printf supports both (!)], however the . is standard programming languages.

$ python -c 'print(1/2)' 
0.5
$ perl -e 'print(1/2)'
0.5
$ echo "1/2" | bc -l
.50000000000000000000

we hit the issue (invalid numeric suffix ".5T") with LANG=en_US.UTF-8 and LC_NUMERIC=de_DE.UTF-8 (which was exported by SendEnv via ssh from one client, whereas another only send LANG and showed the correct behaviour.

[behlendorf]

but make everything more difficult to maintain and also changes the command input depending on locale.

I agree that it would be nice to fully localize everything, but that's definitely a larger job. It wouldn't surprise me if we find a fair number of these assumptions scattered throughout the code base. Forcing the use of a decimal separator sounds like a reasonable way to handle this until it can be localized.

[xdch47]

just want to add, that fully localization has to stop at some point e.g for command arguments.
$ zfs setze Beschränkung=0,5T seems to be overdone.
I would prefer that the input always stays LANG=C style and therefore is the same/independent of the locale.