Bug 97721
| Summary: | lc, uc, ucfirst fail on $1 when matching against while(<>) iterator | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Alex LeDonne <alex.ledonne> | ||||||||
| Component: | perl | Assignee: | Chip Turner <cturner> | ||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||||
| Severity: | low | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 8.0 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i386 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2003-06-27 01:17:55 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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 |
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.