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.