These functions aren't aware of such niceties as thousands separation and
so on. (See L<The localeconv function> if you care about these things.)
-Output produced by print() is also affected by the
-current locale: it depends on whether C<use locale> or C<no locale> is in
-effect, and corresponds to what you'd get from printf()
-in the "C" locale. The same is true for Perl's internal conversions
-between numeric and string formats:
+Output produced by print() is also affected by the current locale: it
+depends on whether C<use locale> or C<no locale> is in effect, and
+corresponds to what you'd get from printf() in the "C" locale. The
+same is true for Perl's internal conversions between numeric and
+string formats:
use POSIX qw(strtod);
use locale;
=item *
-Some systems are broken in that they allow the "C" locale to be
-overridden by users. If the decimal point character in the
-C<LC_NUMERIC> category of the "C" locale is surreptitiously changed
-from a dot to a comma, C<sprintf("%g", 0.123456e3)> produces a
-string result of "123,456". Many people would interpret this as
-one hundred and twenty-three thousand, four hundred and fifty-six.
-
-=item *
-
A sneaky C<LC_COLLATE> locale could result in the names of students with
"D" grades appearing ahead of those with "A"s.
=item B<Output formatting functions> (printf() and write()):
-Success/failure result is never tainted.
+Results are never tainted because otherwise even output from print,
+for example C<print(1/7)>, should be tainted if C<use locale> is in
+effect.
=item B<Case-mapping functions> (lc(), lcfirst(), uc(), ucfirst()):