Merge LC_NUMERIC locale changes branch into blead
authorKarl Williamson <public@khwilliamson.com>
Sat, 4 Jan 2014 20:35:33 +0000 (13:35 -0700)
committerKarl Williamson <public@khwilliamson.com>
Sat, 4 Jan 2014 20:35:33 +0000 (13:35 -0700)
LC_NUMERIC hasn't been implemented quite the same way as the other
locale categories.  And the implementation has been somewhat haphazard.
The other categories have implementations where if you're not under
locale you simply use different operations.  That isn't possible with
LC_NUMERIC, as it may need libc functions that are always subject to the
current locale no matter what Perl thinks.

There are two possible implemantation paths that come to my mind to deal
with this.  One is to keep correctly set the locale that the libc
routines need, and switch to the C locale during those places where it
shouldn't be used.  The other way is the opposite, to keep things in the
C locale generally, and switch when needed.

Unfortunately the implementation (prior to this series of commits) used
a combination of both possibilities.  I am still unsure what the
original intent was (not having spent the time to dig through the
history), or even if there was a consistent intent.

In any event, there has long been infrastructure that facilitates
switching back and forth between the current underlying locale and the C
locale.  However this was not documented until now, and so it is not
surprising that people who came later (including me) did not realize
it existed, and reinvented things, inconsistently.

What I've done here is move to the first implementation path mentioned
above.  I believe this is the one more likely to show up other bugs
during the remainder of the 5.19 development cycle.  I have changed and
added to the infrastructure, so that it knows whether we should be in
the C or the underlying locale, and switches/restores if and only if it
is necessary.  We can change to the other implementation path later
with only minimal code changes.


Trivial merge