Default locale aware float parsing behaviour can be problematic

[helaslo]

Seems like most instances of Unit::ParseString(const string& str, bool useDisplayLocale) are using the default, locale-aware behavior, and this has the potential to subtly break a lot of things.

Found this while testing csvstreamer, it wouldn't display any fractional values, but searching around most instruments which are using this are using the default value too.

This behavior is language dependent, if I run ngscopeclient with LANG=C ngscopeclient it works fine.

Broken behaviour (LANG=hu-HU.utf8 ngscopeclient):

Running with LANG=C:

Way to test it:

LANG=hu_HU.utf8 ngscopeclient

And the test input sequence:

CSV-NAME,CH1,CH2,CH3,CH4,CH5,CH6,CH7,CH8
CSV-CHANNELS,CH1,CH2,CH3,CH4,CH5,CH6,CH7,CH8
CSV-UNITS,V,V,V,V,V,V,V,V
CSV-DATA,1.2,-2,3,4,5,6,-7,8.4
CSV-DATA,1.2,-2,3,4,5,6,-7,8.4
CSV-DATA,1.2,-2,3,4,5,6,-7,8.4
CSV-DATA,1.2,-2,3,4,5,6,-7,8.4
CSV-DATA,1.2,-2,3,4,5,6,-7,8.4

[azonenberg]

The general intent is that we should use the display locale for anything displayed to or typed by the user, and "C" for anything being serialized for portability across instruments and scopesession files of users with different languages.

If csvstream doesn't do this right, that's a bug. If you want to make a more comprehensive pass through library code to find any other places where the same thing is present, that would be great.

[helaslo]

Went over all of them, if I only count the ones which will will be used directly for a floating point value, there are 21 occurrences which didn't have the flag and parsed data in some way, I can make a PR if that is preferred.

My question is:

There are only 5 direct usages ( 4 in Dialog.cpp, 1 in PreferenceDialog.cpp) of this function where I can see that the default, locale-aware behavior is preferred, wouldn't changing those to an explicit true be a better idea, and then the default could be changed in Unit.h to be the more safe value?

Just asking this because I think more driver code will be written in total than GUI, and checking for this continuously can be whack-a-mole game if somebody contributes a driver, it works on their machine, gets merged, then if somebody with a different locale checks the driver it would fail.

Long term solution also could be using two different functions for the two purposes, maybe along with a templated unit type, so different Unit-StorageType mixups could be avoided, while preserving the ability to process them like regular floats/ints