This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/7021] New: locale (faulty?) interfacts with strtod()
- From: "fmarmond at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 11 Nov 2008 14:49:44 -0000
- Subject: [Bug libc/7021] New: locale (faulty?) interfacts with strtod()
- Reply-to: sourceware-bugzilla at sourceware dot org
When using strtod() for converting a string to float, the behavior of strtod is
affected by current locale settings and may fail converting simple value as "1.1".
For example, in French locale, the decimal delimiter is comma ',', and not '.'
It may not be a bug, but a feature, ok, on a certain point of view.
But please consider now that this function is used to decode a string that comes
from a config file (and so, technical, written in english), value will be "1.1"
for example.
It will work as long as the locale is 'english friendly', but this config value
will fail decoding (the "dot 1" will be forgotten) when using an other locale,
let's say french one. => technical layer of a software may fail because
functional part uses certain locale. And what about 3rd parties libraries? They
may be affected by the main application locale policy...
You'll understand better with this little testcase:
/* litle testcase that shows potentially problematic use of stdlib when using locale
* Here, it's not really a problem, as we know when we use french localization...
* But imagine you use user's one? (using: setlocale(LC_ALL,""); )
* And what it you write a 3rd party library, that don't know how the main() prog
will handle localization?!?
* That may be really dangerous!!!
*/
#include "stdlib.h"
#include "stdio.h"
#include "locale.h"
int main(int argc,char** argv)
{
/*default locale is "C", that is equivalent to: setlocale(LC_ALL,"C");*/
const char* value="12.34";
printf("Will decode this string value :%s\n",value);
printf("Locale is default: decoded value=%f\n",strtod(value,NULL));
setlocale(LC_ALL,"fr_FR.UTF-8");
printf("Locale is french: decoded value=%f\n",strtod(value,NULL));
printf("Funny, isn't it?!?\n");
return 0;
}
Here is the runtime:
[fred@will /tmp]% gcc strtod_locale.c -o strtod_locale && ./strtod_locale
Will decode this string value :12.34
Locale is default: decoded value=12.340000
Locale is french: decoded value=12,000000
Funny, isn't it?!?
My suggestion is to make strtod interpret all locales decimal separators (I know
dot and comma, I don't know if some other locales uses other symbols).
Maybe this url may help understand the problem:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/Attic/strtod.c.diff?r1=1.10&r2=1.11&f=h
For a detailed history of the bug, you may refer here:
http://fmarmond.blogspot.com/2008/11/stdlib-and-locale-problems-for-3rd.html
Feel free to contact me!
--
Summary: locale (faulty?) interfacts with strtod()
Product: glibc
Version: 2.8
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper at redhat dot com
ReportedBy: fmarmond at gmail dot com
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=7021
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.