From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 Description of problem: I will attach a script that demonstrates the problem. In a while(<>) loop, matching with /(pattern)/, we need to operate on $1. If we use lc($1), uc($1), ucfirst($1), on the first call to one of those functions, the output is munged: byte 1 and bytes >=7 are correct. For lc, bytes 2 & 4 are replaced with 0x30, bytes 5 & 6 are replaced with 0x00, and byte 3 appears to be 0x02 + the correct value. For uc, byte 2 is 0x30, byte 4 is 0x35, bytes 5 & 6 are still 0x00, and byte 3 appears to be 0x42. This has been tested an reproduced on two different RedHat 8.0 systems with perl-5.8.0-55 installed. This bug does not exist on other perl installations (solaris, cygwin). Version-Release number of selected component (if applicable): perl-5.8.0-55 How reproducible: Always Steps to Reproduce: 1. download the files lchex.pl, test.txt 2. execute lchex.pl < test.txt You can replace test.txt with your own text. In lchex.pl, you can replace the lc function with uc or ucfirst. Actual Results: Output of ./lcbug.pl < test.txt: aaaaAAAA 97 97 97 97 65 65 65 65 97 48 99 48 0 0 97 97 97 97 97 97 97 97 97 97 Expected Results: Expected output: aaaaAAAA 97 97 97 97 65 65 65 65 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 97 Additional info: workarounds exist: Call the function twice on $1 Use extra parentheses on the match, e.g. /((pattern))/, then use $2 Assign $1 into a temporary variable before calling the function Nonetheless, the same non-modifying statement, called twice in succession, should produce the same results each time.
Created attachment 92493 [details] Test case script to demonstrate bug.
Created attachment 92494 [details] test text file, containing "aaaaAAAA" followed by newline
Created attachment 92495 [details] Test case script with hex output, rather than decimal.
To clarify, when I refer to lcbug.pl, that's the first test script. That's the output I showed above. lchex.pl is the second test script, and works just as well as referred to in the steps to reproduce. Sorry for any confusion.
this is a known issue with that perl; you can try the perl in RHL9 or in Rawhide, which should solve this problem