#52 Locale settings influence YARP behavior

[dantard]

Hi,
we found a BUG in yarp related with the locale setting of the computer used in the Bottle Implementation.
Concretely the code assumes that the decimal separator is always a point while in some locales (ex spanish) the point is replaced by a comma.
It provokes yarp to misinterpret double values as strings in toString/fromString events and on bottle exchanges through a network.

The following code shows the problem (assuming a Spanish environment locale):

setlocale(LC_ALL,"");

Bottle b;
b.addDouble(3.2);
b.addDouble(4.2);
b.addDouble(3.0);

char txt[1000];
strcpy(txt,b.toString().c_str());
cout << "b: " <<b.toString().c_str() << endl;
cout << "txt: " << txt << endl;
Bottle c;
c.fromString(txt);
cout << "c: " << c.toString().c_str() << endl;

Result:
b: 3,200000.0 4,200000.0 3,000000.0
txt: 3,200000.0 4,200000.0 3,000000.0
c: "3,200000.0" "4,200000.0" "3,000000.0"

The patch for BottleImpl.cpp attached *should* solve the problem.

Best regards.

[dantard]

[Paul Fitzpatrick]

Thanks for pointing this out, and for providing a fix. Unfortunately we cannot apply this patch to YARP, because the sstream header file is not a permitted dependency according to our policy. But at least this patch is here for individual users with this problem.

Any suggestions for how to solve this problem using common C functions, or functions available in the ACE library?

[dantard]

Hi all,
this new patch (patch_BottleImpl_bug_locale) solves the bug using only c functions. Hope this helps.

Cheers.

[dantard]

Solves locale BUG

[Paul Fitzpatrick]

Thanks for the C-only patch! Sorry for the delay applying it, I just need to check that localeconv is sufficiently widely implemented on supported platforms. It looks good...

[Paul Fitzpatrick]

I've committed a change based on your patch, thank you. I avoided using strstr/floor/ceil just so I wouldn't have to figure out how portable they are. I couldn't figure out if localeconv is really always available so made the code conditional on LC_NUMERIC being defined.

I'll leave this bug open for a while just in case I messed up. Thanks again Danilo,
Paul