[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-glpk] str2num() is locale dependent
From: |
Andrew Makhorin |
Subject: |
Re: [Bug-glpk] str2num() is locale dependent |
Date: |
Sun, 24 May 2009 16:59:37 +0300 |
Hi Xypron,
> I tried to call the GLPK library from Java under Debian.
> I received the following error:
> transp.mod:58: d requires numeric data
> Context: ...peka 275 ; param d : New-York Chicago Topeka := Seattle 2.51
> The problem could be traced back to
> val = strtod("2,1", &endptr);
> printf("strtod('2,1') = %f\n", val);
> val = strtod("2.1", &endptr);
> printf("strtod('2.1') = %f\n", val);
> printing
> strtod('2,1') = 2,100000
> strtod('2.1') = 2,000000
> strtod is locale-dependent.
> In Germany ',' is the decimal separator.
> I found the following description on the net:
> The radix character is defined in the program's locale (category
> LC_NUMERIC).
> In the POSIX locale, or in a locale where the radix character is not
> defined,
> the radix character defaults to a period ('.').
> I guess the GLPK library should work whatever locale the main program is
> using.
> Could you, please, fix function
> int str2num(const char *str, double *_val)
> in glplib11.c not to be locale dependent.
> The following code could do the trick:
> #include <locale.h>
> ...
> struct lconv * lc;
> lc = localeconv();
> setlocale ( LC_NUMERIC, 'C');
> ...
> setlocale ( LC_NUMERIC, lc->decimal_point);
> as locales cannot be reset easily with standard C - functions
> probably the best thing to do is to replace the decimal point
> by lconv->decimal_point before calling str2num().
>
> lcconv can be retrieved by calling localeconv().
Thank you for your bug report.
I think that changing locale in str2num is not a good idea
(this would be the same as changing locale, say, in the exp function
for locales where due to government regulations e is exactly 2, not
2.71828... :) In my opinion, locale-dependent strtod is one of silliest
things in the standard, because there is no alternate locale-independent
version, while at the same time the standard says nothing about
locale-specific decimal separator in atof and scanf. So I wouldn't like
to use locale functions at all in the glpk code.
Probably strtod should be replaced by something like xstrtod.
BTW, in the standard C on program startup the current locale is "C".
Is locale changed intentionally in your application?
Andrew Makhorin