develooper Front page | perl.perl5.porters | Postings from August 2013

Re: [perl #54728] PathTools-3.27 triggers a bug in Perl

Thread Previous | Thread Next
Ed Avis
August 9, 2013 10:27
Re: [perl #54728] PathTools-3.27 triggers a bug in Perl
Message ID:
IMHO, this is a longstanding misfeature in Perl.  It is easy to write

    our $options = 'debug';
    sub foo {
       say 'debug flag set' if $options =~ /debug/;
       say $_[0] + $_[1];

And it is also easy to write

    my $x = '123';
    $x =~ /(\d+)/ or die;
    foo(5, $1);

No warning is given in either case.  So, depending on which way you look at
it, you have a subroutine foo() which is buggy if called with $1, or you have
some buggy user code calling it, depending on the details of how foo() is

It would be far better if $1 were truly localized, so that the regexp match
inside foo() did not have any effect on the $1 used by the calling code
(which has been passed by reference).

It would even be better, or at least easier to understand, if $1 were global.
Then the puzzled programmer could see that calling foo() has modified $1 as
a side effect.

But at present $1 exists in a strange halfway house where it is neither truly
global nor truly local.  It's a global variable where Perl shuffles around the
value behind the scenes; but this does not give the same behaviour as:

    our $o;
    sub foo {
        local $o = 'a';
        say $_[0] + $_[1];
    local $o = 123;
    foo(5, $o);

Even though foo() is setting the value of $o, this doesn't break the
argument passing because $o is localized.  If $1 were localized properly
then it wouldn't break either.

Ed Avis <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About