AW: locales support in sscanf. Bug 35364

[Schirmacher, Rolf]

-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Pascal Dupuis
Gesendet: Montag, 17. Dezember 2012 17:39
An: Jordi Gutiérrez Hermoso
Cc: address@hidden
Betreff: Re: locales support in sscanf. Bug 35364

2012/12/17 Jordi Gutiérrez Hermoso <address@hidden>:
> On 17 December 2012 06:30, Andreas Weber <address@hidden> wrote:
>> I think the right way if we want to test this is to
>> * get a list of all locales which use a comma as decimal separator
>> * get the currently available locales
>> * compare which of them use comma as decimal separators
>> * test these
>
> I like this proposal, but it's only a stopgap for now.
>
> Do you remember jwe's suggestion that we really need a way to figure 
> out l10n for the C-style I/O functions at a more fundamental level 
> than just for sscanf?
>
> - Jordi G. H.

There is a bigger issue here. As I implemented the patch in sscanf, the locales 
modification only touches a C++ stream created as a local variable. This way, 
using an unknown or wrong locale names has only limited effects. If we use 
something wider with std::setlocale, then it will influence ALL 
locale-sensitive C library. This implies that all data and input files must be 
encoded with the right locale. If something goes wrong during startup, this 
implies more efforts to debug it.

In the first place, I wrote this patch in the following context:
- an experiment was driven by LabView on a Windows PC machine, LabView and 
locales set to french, no way to get out. Exported data in CSV files were thus 
using comma as decimal separator
- I had to parse those CSV file in Octave, using the right format. The header 
contained a few comments, so touching comma occuring in text strings was to be 
avoided ...

More generally, locales support is required to interfere with programs 
producing or reading data expressed as textual representation. Do you see other 
cases were locales support would help ?

To get back to the original problem, I know its annoying to have a build 
failure. Ideally, during the configure or build stage, things should go as:
1) detect installed locales
2) for each of them, test if the decimal separator is a comma instead of a dot
3) only perform a test for those locales

Now, the drawback is that the testing becomes sensitive to the number of 
locales, which ranges from "none" to "a lot": on my Mac (OS X 10.8), there are 
around 200 installed locales ...

Regards

Pascal



Just to add my 2 ct:
We should be very careful with locale support... living in Germany with a comma 
as decimal point it is very confusing with locale - aware numerical inputs. 

The key issue is data transfer, as Pascal wrote. A classical issue is copy & 
paste or csv data - you always have to consider any kind of side effects. On 
the other side, I would not like to see octave (and its scripts!) to require 
changes in the decimal point - I guess, we would get endless errors (at least 
at the beginning). Designating the locale at the beginning of every *.m-file is 
also probably not the best solution, is it?

So, it really boils down to data exchange with "locale-aware" software - csv, 
spreadsheets, copy&paste at the gui. We should probably try to contain it to 
this area, not to affect our language, the command prompt, etc. in general.

Regards,

Rolf