Red Hat Bugzilla – Bug 1025906
Locale::Maketext interpolating escaped backslashes improperly
Last modified: 2015-07-22 01:59:27 EDT
Description of problem:
When a literal backslash is in an L10N value, it is treated nonuniformly by the Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts (per https://bugzilla.redhat.com/show_bug.cgi?id=884354). The result depends on unrelated parts of the string.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a language token, whose value is 'Some data\n'
2. Query the language token through Locale::Maketext ($lh->maketext($tag))
The behavior changes in the following cases:
1) If the value contains a tokenized field, behavior depends on whether there is a trailing newline:
'[_1]Some data\n' => 'Some data\n'
'[_1]Some data\n'."\n" => 'Some data\\n
2) If the escaped backslash is in a function call, it behaves as expected:
'Some data[sprintf,\n]' => 'Some data\n'
NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from CPAN) behave exactly the same as each other, and they all produce just a single '\' before the 'n'.
The 'Some data\n' is due to back-porting the fix to perl 5.10.1.
The parameterized case behaves for me differently and is caused by the changes in the fix. Even latest Locale::Maketext is affected.
Created attachment 819144 [details]
Created attachment 819195 [details]
Upstream partial fix for non-parametrized case
Created attachment 819662 [details]
Proposed fix for parametrized case
Created attachment 822328 [details]
Fix accepted by upstream in slightly different form. Only this one is needed to fix the regression.
Created attachment 822402 [details]
Use this script for tests.
Created attachment 861802 [details]
Upstream fix ported to 5.8.8
This adds additional required fix for literal strings.
Dan, if this is an issue for you on productions systems, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution.
Thanks, Joe. I was able to work around this by wrapping the character escapes within sprintf function calls, so production systems are no longer affected.
Created attachment 977122 [details]
Upstream fix ported to 5.10.1
How to test:
(1) Run the reproducer from attachment #8 [details].
(2) Check the output:
Before: Some back-slashes are doubled.
After: There are only single back-slashes.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.