Re: printf and locale

[Rik]

On 02/25/2013 12:27 AM, Pascal Dupuis wrote:
> 2013/2/25 John W. Eaton <address@hidden>:
>
>> Whatever we decide, we need to take the following into consideration for
>> compatibility with Matlab:
>>
>> http://www.mathworks.com/help/matlab/matlab_env/how-the-matlab-process-uses-locale-settings.html
>>
>> Note that Matlab unconditionally uses the C locale for LC_NUMERIC. Using
>> something different is just begging for future bug reports about
>> compatibility.
>>
> Wise point. I was a bit surprised that even ja_JP.UTF-8 and
> ja_JP.eucJP can not be  safely mixed.
>
> The issue I had to solve in the first place was READING csv files into
> Octave. We should indeed align ourselves on MatLab to avoid potential
> issues, yet provide some mean to deal with locales on external files.
> The original patch I wrote was an extension to scanf. What about
> extending the format strings used by scanf and printf to understand
> the '%,;%f' and '%.;%f' extension ? This way every deviation from the
> LC_NUMERIC "standard" behaviour must be explicitelly requested by the
> user. No base code from Octave should use this mechanism, in order to
> avoid issues and bug reports. So I repeat the question: Is "'%,;%f" a
> C standard or some extension provided by National Instruments ?
2/25/13

Pascal,

It appears that this is a National Instruments extension only.  Java has a
'%,' format code but it means to use a thousand's separator, not to change
the radix.  The Linux kernel does not make mention of it
(http://www.kernel.org/doc/man-pages/online/pages/man3/sprintf.3.html).

If this extension were added, what kind of changes would we need to
implement in Octave?  The issue I see is that if the underlying scanf C or
C++ function does not support this extension then we will need to rewrite
lots of patterns.  For example, the format string "%,;%f" might be expanded
to "%f,%f", but then scanf will fail if the actual number is ",123".  It
looks like a mess that is better fixed by regular expressions and at that
point it would probably be easier to convert a CSV file via Perl or some
other language.

--Rik