Skip Menu |
 

This queue is for tickets about the NEXT CPAN distribution.

Report information
The Basics
Id: 36956
Status: resolved
Priority: 0/
Queue: NEXT

People
Owner: Nobody in particular
Requestors: norbi [...] nix.hu
Cc:
AdminCc:

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



MIME-Version: 1.0
X-Spam-Status: No, hits=-6.6 required=8.0 tests=BAYES_00,PERLBUG_CONF
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i486-pc-linux-gnu)
Content-Type: multipart/mixed; boundary="MP_w_a/c7l1WZdSXPUbrJlPd0J"
X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at lucky.nix.hu
Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 21C244D8070 for <bug-NEXT [...] rt.cpan.org>; Fri, 20 Jun 2008 10:09:38 -0400 (EDT)
Received: (qmail 16850 invoked from network); 20 Jun 2008 14:09:37 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 20 Jun 2008 14:09:37 -0000
Received: from lucky.nix.hu (HELO lucky.nix.hu) (212.92.3.233) by 16.mx.develooper.com (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jun 2008 07:06:06 -0700
Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8A9321008A; Fri, 20 Jun 2008 16:05:25 +0200 (CEST)
Received: from lucky.nix.hu ([127.0.0.1]) by localhost (lucky.nix.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfulioD+G7wF; Fri, 20 Jun 2008 16:05:10 +0200 (CEST)
Received: from vger.nix.hu (dsl4E5C28D9.pool.t-online.hu [78.92.40.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "vger.nix.hu", Issuer "nix.hu" (verified OK)) by lucky.nix.hu (Postfix) with ESMTP id 5BA0E10086; Fri, 20 Jun 2008 16:05:09 +0200 (CEST)
Received: from vger.nix.hu (localhost [127.0.0.1]) by vger.nix.hu (Postfix) with ESMTP id 46AB6990EE; Fri, 20 Jun 2008 16:05:09 +0200 (CEST)
Delivered-To: cpan-bug+NEXT [...] diesel.bestpractical.com
Subject: NEXT messes up $1 and $2 passed as arguments
Return-Path: <norbi [...] nix.hu>
X-Original-To: bug-NEXT [...] rt.cpan.org
X-Spam-Check-BY: 16.mx.develooper.com
Date: Fri, 20 Jun 2008 16:05:08 +0200
X-Spam-Level: *
Message-Id: <20080620160508.2a5438a9 [...] vger.nix.hu>
To: bug-NEXT [...] rt.cpan.org
From: BUCHMULLER Norbert <norbi [...] nix.hu>
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: US-ASCII
Content-Length: 3280
Download (untitled) / with headers
text/plain 3.2k
If $1 or $2 is passed as arguments to a sub called via NEXT, the sub will receive "NEXT" and the sub name in the corresponding arguments, instead of the original value of $1 and $2 before the $obj->NEXT::somesub(...) call. (Similarly some of the other regex punctuation vars are affected.) See the 'NEXT-regex_match_variable_bug.pl'. The problem originates from the peculiar scoping of the regex match variables, and that members of @_ are aliases to the corresponding members of the actual argument list: "The numbered match variables ($1, $2, $3, etc.) and the related punctuation set ($+, $&, $`, $', and $^N) are all dynamically scoped until he end of the enclosing block or until the next successful match, whichever comes first." from perlre "The array @_ is a local array, but its elements are aliases for the actual scalar parameters." from perlsub See 'Perl-regex_match_variable_bug.pl' and #23140 and #22369 in rt.perl.org. Now there are three ways to avoid this unintended behaviour: A) Enclosing all the code that modifies the regex vars into an inner scope inside NEXT::AUTOLOAD, and never use directly @_ from this inner scope. (We must not use @_ from inside that scope, since in the inner scope those members of @_ that are aliased to $1, $2, etc. point to the $1, $2, etc. of the last successfully matched regex in the *inner* scope.) B) Creating a copy of @_ at the beginning of NEXT::AUTOLOAD, and using that instead of @_. (This way we create a copy of each member of @_, there will be no aliases.) C) Not passing regex match- or punctuation vars as arguments. (ie. considering this behaviour as a feature) Note that local()-izing the regex match- and punctuation variables in the NEXT::AUTOLOAD will not work, first, because that would hide their previous value (and we want to pass that on, encapsulated in @_), second, because it does not work for regex vars. :-) Now, we must drop B) as copying @_ in NEXT::AUTOLOAD will break outbound parameter passing. (The user can modify the actual variables in the argument list via $_[1], $_[2], ..., and NEXT does not break it currently.) We must drop C) as well, because if someone is aware of the above problem and writes his/her subs carefully to not modify regex vars inadvertently, putting NEXT in the call chain should not ruin that. As far as I can see, there only remains A). So I created a quick and dirty fix: since in NEXT.pm we use none of the regex vars, simply wrapping all the match and substitute expressions in 'do { }' blocks does the trick of putting them in an inner scope. See 'NEXT-regex_match_variable_fix.diff'. The test cases all pass, and I also did a rough performance measurement, and it seems that the patch has no negative effect. (I also added a new testcase for this regex variable problem.) A nicer solution would require refactoring the code in the sub to separate those parts that use regex matches or substitutions in an innner scope (or inner scopes) and collect those parts that use @_ but no regexes in the outer scope. But that would be hairy, as I can see. Note: I only considered NEXT::AUTOLOAD above, but the same applies to all the other subs in NEXT.pm (and the patch fixes them, too). norbi Perl version: see 'Perl-version.txt' NEXT.pm version: 0.60
content-type: application/x-perl; name="NEXT-regex_match_variable_bug.pl"
content-disposition: attachment; filename="NEXT-regex_match_variable_bug.pl"
Content-Transfer-Encoding: base64
Content-Length: 466

Message body is not shown because sender requested not to inline it.

content-type: application/x-perl; name="Perl-regex_match_variable_bug.pl"
content-disposition: attachment; filename="Perl-regex_match_variable_bug.pl"
Content-Transfer-Encoding: base64
Content-Length: 405

Message body is not shown because sender requested not to inline it.

content-type: text/x-patch; name="NEXT-regex_match_variable_fix.diff"
content-disposition: attachment; filename="NEXT-regex_match_variable_fix.diff"
Content-Transfer-Encoding: 7bit
Content-Length: 3558

Message body is not shown because sender requested not to inline it.

content-type: text/plain; charset="utf-8"; name="Perl-version.txt"
content-disposition: attachment; filename="Perl-version.txt"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: ascii
Content-Length: 3166

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
In-Reply-To: <rt-3.6.HEAD-2172-1213985859-721.36956-3-0 [...] rt.cpan.org>
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i486-pc-linux-gnu)
References: <RT-Ticket-36956 [...] rt.cpan.org> <20080620160508.2a5438a9 [...] vger.nix.hu> <rt-3.6.HEAD-2172-1213985859-721.36956-3-0 [...] rt.cpan.org>
X-Virus-Checked: Checked by ClamAV on 16.mx.develooper.com
X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at lucky.nix.hu
Content-Type: multipart/mixed; boundary=MP_o3_MCn7x8CCRtJNixVEKBwq
Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id A4AD34D8118 for <bug-NEXT [...] rt.cpan.org>; Fri, 4 Jul 2008 14:41:49 -0400 (EDT)
Received: (qmail 1263 invoked from network); 4 Jul 2008 18:41:49 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 4 Jul 2008 18:41:49 -0000
Received: from lucky.nix.hu (HELO lucky.nix.hu) (212.92.3.233) by 16.mx.develooper.com (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Jul 2008 11:41:44 -0700
Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 842551007A for <bug-NEXT [...] rt.cpan.org>; Fri, 4 Jul 2008 20:41:37 +0200 (CEST)
Received: from lucky.nix.hu ([127.0.0.1]) by localhost (lucky.nix.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3upspysTYsR for <bug-NEXT [...] rt.cpan.org>; Fri, 4 Jul 2008 20:41:22 +0200 (CEST)
Received: from vger.nix.hu (dsl4E5C2A02.pool.t-online.hu [78.92.42.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "vger.nix.hu", Issuer "nix.hu" (verified OK)) by lucky.nix.hu (Postfix) with ESMTP id 0BE7F10089 for <bug-NEXT [...] rt.cpan.org>; Fri, 4 Jul 2008 20:41:18 +0200 (CEST)
Received: from vger.nix.hu (localhost [127.0.0.1]) by vger.nix.hu (Postfix) with ESMTP id E8764990EE for <bug-NEXT [...] rt.cpan.org>; Fri, 4 Jul 2008 20:41:17 +0200 (CEST)
Delivered-To: cpan-bug+NEXT [...] diesel.bestpractical.com
Subject: Re: [rt.cpan.org #36956] AutoReply: NEXT messes up $1 and $2 passed as arguments
Return-Path: <norbi [...] nix.hu>
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: bug-NEXT [...] rt.cpan.org
Date: Fri, 4 Jul 2008 20:41:17 +0200
X-Spam-Level: *
Message-Id: <20080704204117.5d961c1d [...] vger.nix.hu>
To: bug-NEXT [...] rt.cpan.org
From: BUCHMULLER Norbert <norbi [...] nix.hu>
RT-Message-ID: <rt-3.6.HEAD-26993-1215196914-1855.36956-0-0 [...] rt.cpan.org>
Content-Length: 0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: utf-8
Content-Length: 343
Download (untitled) / with headers
text/plain 343b
Testing if $& is not modified in AUTOLOAD is a stricter constraint than checking for the modification of $1, so I changed the test suite (so it will catch regex matches that do not capture but alter the other regex vars). (And renamed the test suite to 'regex_vars.t' as it has almost nothing to do with dynamically scoped variables.:-) norbi
content-type: text/troff; name="regex_vars.t"
content-disposition: attachment; filename="regex_vars.t"
Content-Transfer-Encoding: 7bit
Content-Length: 817
Download regex_vars.t
text/x-perl 817b

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
In-Reply-To: <20080620160508.2a5438a9 [...] vger.nix.hu>
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Disposition: inline
Charset: utf8
References: <20080620160508.2a5438a9 [...] vger.nix.hu>
Message-Id: <rt-3.6.HEAD-8616-1219075289-460.36956-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 179
Download (untitled) / with headers
text/plain 179b
A cleaner solution might be a core enhancement to tell a regexp match not to touch $1 and $2. I have suggested this in <http://rt.perl.org/rt3/Public/Bug/Display.html?id=58072>.


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.