Make printf, sprintf respect 'use locale' for radix

When called from outside the lexical scope of 'use locale', these now
always print a dot for the decimal point character.

This change is actually done in Perl_sv_vcatpvfn_flags, which is common
to many things, but the principal external effect that I could determine
is on printf and sprintf.

Without this change, unrelated code can change the locale, thus
affecting what an unsuspecting application prints.

1 files changed, 17 insertions, 7 deletions

diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index 775a06927b..fc0798592e 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -37,13 +37,23 @@ L</Selected Bug Fixes> section.
 
 =head1 Incompatible Changes
 
-XXX For a release on a stable branch, this section aspires to be:
-
-    There are no changes intentionally incompatible with 5.XXX.XXX
-    If any exist, they are bugs, and we request that you submit a
-    report.  See L</Reporting Bugs> below.
-
-[ List each incompatible change as a =head2 entry ]
+=head2 Locale decimal point character no longer leaks outside of S<C<use locale>> scope
+(with the exception of C<$!>)
+
+This is actually a bug fix, but some code has come to rely on the bug
+being present, so this change is listed here.  The current locale that
+the program is running under is not supposed to be visible to Perl code
+except within the scope of a S<C<use locale>>.  However, until now under
+certain circumstances, the character used for a decimal point (often a
+comma) leaked outside the scope.
+
+This continues the work released in Perl v5.19.1.  It turns out that
+that did not catch all the leaks, including C<printf> and C<sprintf> not
+respecting S<C<use locale>>.  If your code is affected by this change,
+simply add a S<C<use locale>>.
+
+Now, the only known place where C<'use locale'> is not respected is in
+the stringification of L<$!|perlvar/$!>.
 
 =head1 Deprecations