Bug 97721 - lc, uc, ucfirst fail on $1 when matching against while(<>) iterator
lc, uc, ucfirst fail on $1 when matching against while(<>) iterator
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
8.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Chip Turner
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-19 14:48 EDT by Alex LeDonne
Modified: 2007-04-18 12:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-26 21:17:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test case script to demonstrate bug. (210 bytes, text/plain)
2003-06-19 14:49 EDT, Alex LeDonne
no flags Details
test text file, containing "aaaaAAAA" followed by newline (9 bytes, text/plain)
2003-06-19 14:49 EDT, Alex LeDonne
no flags Details
Test case script with hex output, rather than decimal. (219 bytes, text/plain)
2003-06-19 14:53 EDT, Alex LeDonne
no flags Details

  None (edit)
Description Alex LeDonne 2003-06-19 14:48:11 EDT
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.
Comment 1 Alex LeDonne 2003-06-19 14:49:05 EDT
Created attachment 92493 [details]
Test case script to demonstrate bug.
Comment 2 Alex LeDonne 2003-06-19 14:49:46 EDT
Created attachment 92494 [details]
test text file, containing "aaaaAAAA" followed by newline
Comment 3 Alex LeDonne 2003-06-19 14:53:43 EDT
Created attachment 92495 [details]
Test case script with hex output, rather than decimal.
Comment 4 Alex LeDonne 2003-06-19 14:56:20 EDT
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.
Comment 5 Chip Turner 2003-06-26 21:17:55 EDT
this is a known issue with that perl; you can try the perl in RHL9 or in
Rawhide, which should solve this problem

Note You need to log in before you can comment on or make changes to this bug.