[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
> 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

reply via email to

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