More issues with locale LC_NUMERIC

I have audited the Perl core source code looking for more instances of 
where LC_NUMERIC could cause the radix character to not be a dot even 
outside the scope of 'use locale'.   I found four.

Three of them are
	Perl_my_sprintf
	Perl_my_snprintf
	Perl_my_vsnprintf
These are all documented as being wrappers for their respective C 
library routines, and in fact the first one is defined only if the C 
library is very old, and needs a wrapper to get consistent results with 
later versions.  What I propose doing with these is simply to document 
the fact that the functions they wrap are subject to the current locale 
set in the program, and whether they are in a 'use locale' scope is 
irrelevant.

The fourth is Perl_sv_vcatpvfn_flags() (and its callers).  I tried to 
look at all calls that resolve to this, and found none in the core where 
the locale should matter as far as the decimal point goes.  There would 
be potentially many such calls if the locale calls for a non-null 
thousands separator or similar, as I understand some Norwegian locales 
do.  The decimal point shows up only in floating point formats, and the 
few instances in the core that I found that call this function with such 
a format, already set and restore the locale around the call, so only a 
dot ever gets output.

The question is do we leave things as they are, documenting the issues; 
or do we change this function to always print a dot outside the scope of 
locale?  Making the change should not affect the Perl core, unless my 
audit overlooked something.  But it could affect XS code, perhaps for 
the better, perhaps for the worse.  I'd like to get other people's 
opinions on this.  Note that leaving it alone can lead to spooky action 
at a distance, where some module changes the locale, affecting a totally 
unrelated module.

• More issues with locale LC_NUMERIC by Karl Williamson
• Re: More issues with locale LC_NUMERIC by Ricardo Signes