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
From:
Ed Avis
Date:
August 9, 2013 10:27
Subject:
Re: [perl #54728] PathTools-3.27 triggers a bug in Perl
Message ID:
loom.20130809T121441-55@post.gmane.org
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
implemented.

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 <eda@waniasset.com>





Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About