There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
UPDATE: Since writing this post, I've managed to reproduce the lib/locale.t failure on my Ubuntu-16.04 box by switching locale to LANG=de_DE.UTF-8.
I now just need to make sense of what I'm seeing. The failures might be related to the fact the my locale (like some European ones) uses a comma (,) as decimal separator, unlike a dot (.) as expected by "C" locale Then I wonder if I might be able to strike the same issues on my Ubuntu-16.04 box by messing with its locale settings. I'll have to at least give that a try. I've no experience with messing with locale settings - but I expect that google has lots of advice to offer on how to do this. I'm sure that my patches affect only the values that are assigned - they change nothing about the way that values are displayed. If C's strtod() doesn't honor the locale when parsing the input string, then that would cause breakage. However, in such a case I would expect more extensive breakage than just a lib/locale.t failure. And, of course, such a perl would have no business in defining Perl_strtod in the first place - and the default that allows the defining of $Config{d_strtod} ought to be changed. Could you test one more thing for me, please ? When (if) you have the time, could you rebuild that source with the addition of -Ud_strtod to the configure args. That is: I'm hopeful that will allow the lib/locale.t tests to pass without introducing more breakage elsewhere. Thank you very much for the trouble you've taken and the information you've provided. Cheers, Rob In reply to Re^5: Avoiding perl's Atof when assigning floating point values
by syphilis
|
|