Front page | perl.perl5.porters |
Postings from March 2014
Ricardo Signes <perl.p5p@rjbs.manxome.org> writes: > 6. Gconvert() obeys LC_NUMERIC without "use locale" > https://rt.perl.org/Ticket/Display.html?id=121317 > > Karl asserts that the change is correct, although a new macro may be > warranted. I think I agree. Dissenters should dissent soon. It would > probably be nice to have that wrapper available soon, too. The LC_NUMERIC change does not only affesct Gconvert, but any XS functionality using functions like strtod or sprintf with floating point conversion specifiers. Without even doing systematic CPAN smoking I found quite a number of CPAN modules which are broken because of this. The already mentioned list in RT #121317: Number::Format JSON::XS String::Print Cpanel::JSON::XS SHARYANTO::Number::Util Tk (if you happen to not get the segfault happening on some architectures) Devel::Cover Some more: MJEMMESON/Geo-JSON-0.006.tar.gz WYANT/Astro-satpass-0.061_04.tar.gz CFRANKS/HTML-FormFu-1.00.tar.gz SISYPHUS/Math-GMPf-0.37.tar.gz I suspect that every CPAN module using strtod/sprintf indirectly through a shared library is broken. Here's an example how to reproduce the problem using Inline::C. Just set LC_NUMERIC or LANG or LC_ALL to something which is using "," as the floating point separator, e.g "de_DE.UTF-8":Thread Previous | Thread Next