octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locales support in sscanf. Bug 35364


From: Pascal Dupuis
Subject: Re: locales support in sscanf. Bug 35364
Date: Mon, 17 Dec 2012 17:39:29 +0100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]