Skip Menu |

This queue is for tickets about the Scalar-List-Utils CPAN distribution.

Report information
The Basics
Id: 31054
Status: resolved
Priority: 0/
Queue: Scalar-List-Utils

People
Owner: Nobody in particular
Requestors: paul.bijnens [...] xplanation.com
Cc:
AdminCc:

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



Subject: small bug in Scalar::Util
Date: Thu, 29 Nov 2007 10:35:03 +0100
To: bug-Scalar-List-Utils [...] rt.cpan.org
From: Paul Bijnens <Paul.Bijnens [...] xplanation.com>
I encountered this little bug after an upgrade of perl 5.8.8 that fixed the pcre vulnerability on CentOS 5, which suddenly failed to have the XS version of Scalar::Util (not sure why that happened). Just force an install of the Scalar::Util package fixed that problem, but while investigating what was wrong, I encountered another small bug. In Scalar::Util the function export_fail tests this (line 28-31): if (grep { /^(dualvar|set_prototype)$/ } @_ ) { require Carp; Carp::croak("$1 is only avaliable with the XS version"); } The bug is that the reg.exp. tries to set $1, but that var goes out of scope outside the block, resulting in an undefined variable in the croak string and no indication that it was actually dualvar or set_prototype that triggered the error. test: perl -le '@a=("A".."H"); if (grep { /^(C)$/ && print "in[$1]"} @a) { print "out[$1]" }' Easiest fix: if (grep { /^(?:dualar|setprototype)$/ @_ ) { require Carp; Carp::croak("dualvar and set_prototype only available with the XS version"); } And while we're at it, the previous tests in the same function could also replace the catching parentheses "(xx|yy)" with just grouping constructions (?:xx|yy) for a marginal speedup. -- Paul Bijnens, xplanation Technology Services Tel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512 http://www.xplanation.com/ email: Paul.Bijnens@xplanation.com *********************************************************************** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***********************************************************************
On Thu Nov 29 05:03:08 2007, paul.bijnens@xplanation.com wrote: Show quoted text
> > I encountered this little bug after an upgrade of perl 5.8.8 that > fixed the pcre vulnerability on CentOS 5, which suddenly failed to > have the XS version of Scalar::Util (not sure why that happened). > Just force an install of the Scalar::Util package fixed that problem, > but while investigating what was wrong, I encountered another small bug. > > > In Scalar::Util the function export_fail tests this (line 28-31): > > if (grep { /^(dualvar|set_prototype)$/ } @_ ) { > require Carp; > Carp::croak("$1 is only avaliable with the XS version"); > } > > The bug is that the reg.exp. tries to set $1, but that var goes > out of scope outside the block, resulting in an undefined variable > in the croak string and no indication that it was actually dualvar > or set_prototype that triggered the error. > > test: > perl -le '@a=("A".."H"); > if (grep { /^(C)$/ && print "in[$1]"} @a) { print "out[$1]" }' > > Easiest fix: > > if (grep { /^(?:dualar|setprototype)$/ @_ ) { > require Carp; > Carp::croak("dualvar and set_prototype only available with the XS > version"); > } > > And while we're at it, the previous tests in the same function could > also replace the catching parentheses "(xx|yy)" with just grouping > constructions (?:xx|yy) for a marginal speedup. >
Alternative fix: { my @vars; if (grep { /^(dualvar|set_prototype)$/ and push @vars, $1 and 1 } @_ ) { require Carp; Carp::croak("@vars is only avaliable with the XS version"); } } This would show an error message for only the variable which actually failed, although grammtically incorrect if both (dualvar and set_prototype) are specified in the import list. Regards, Slaven
This bug appears to be resolved in the 'next' branch in git. -- rjbs