Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 40590
Status: resolved
Priority: 0/
Queue: CGI

People
Owner: MARKSTOS [...] cpan.org
Requestors: hsw [...] rambler.ru
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: CGI::Utils::unescape() have double EBCDIC detection
Download (untitled) / with headers
text/plain 330b
CGI::Utils::unescape() have: $EBCDIC = "\t" ne "\011"; this variable set in begging of Utils.pm btw, compare: perl -MO=Deparse -e '$EBCDIC = "\t" ne "\011"; if ($EBDIC) { 1 } else { 2 }' and perl -MO=Deparse -e 'sub EBCDIC(){"\t" ne "\011"}; if (EBDIC) { 1 } else { 2 }' In second code optimizer remove unuseful comparation.
On Sat Nov 01 07:29:54 2008, http://id.rambler.ru/users/hsw/ wrote: Show quoted text
> CGI::Utils::unescape() have: > $EBCDIC = "\t" ne "\011"; > this variable set in begging of Utils.pm
I can confirm what you are reporting: #EBCIDIC is set at the top of Utils.pm, and also calculated every time that unescape() is called. However, I'm concerned about changing it because I'm afraid there's some compatibility issue with having $EBCIDIC defined inside of the routine. It certainly makes it a litlte easier to read when it doesn't refer to a remote global variable. What seems like perhaps a better idea to me is create a new routine: sub _is_EBCIDIC { $EBCIDIC = "\t" ne "\011" unless defined $EBCIDIC; return $EBCIDIC; } It would be nice to get rid of the global variable completely, but that doesn't seem possible unless you recalculate the value every time, or only apply the optimization to OO calls, where we can stuff the stored value in the object. But all my talk is likely just premature optimization, since "\t" ne "\011" likeely takes virtually no time to compute. Mark
Download (untitled) / with headers
text/plain 183b
Since there's been no further interest in this case in the past three years, I'm going to just consider it resolved. It sounds like the current behavior is correct, if not optimal.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.