Closed p5pRT closed 17 years ago
It is possible to use simple expressions in (?{...}) constructs\, such as (?{123})\, the idea being that they could be picked up afterwards by reading the contents of $^R.
When optional (?:...)? patterns are used\, the engine appears to become confused and $^R is set to the value of the expression prior to the optional part. It can be shown that the code blocks are in fact executed. Code with side effects (pushing values onto an array) is run\, and the expected results are observed after the match. The problem occurs only for simple expressions.
This behaviour is seen in 5.005_03\, 5.8.5 and 5.8.6.
There do not appear to be any tests that check how $^R should behave. The following file is an attempt to improve matters.
(The following tests all pass except for the following:
not ok 8 - $^R == 8 # Failed test (./vr at line 21)
$^R is in fact equal to 7).
__TEST_FILE_BEGIN__ use Test::Simple tests => 26;
$^R = undef; ok( 'a' =~ /^a(?{1})(?:b(?{2}))?/\, 'a =~ ab?' ); ok( $^R == 1\, '$^R == 1' );
$^R = undef; ok( 'abc' !~ /^a(?{3})(?:b(?{4}))$/\, 'abc !~ a(?:b)$' ); ok( !defined $^R\, 'undef 2nd' );
$^R = undef; ok( 'ab' =~ /^a(?{5})b(?{6})/\, 'ab =~ ab' ); ok( $^R == 6\, '$^R == 6' );
$^R = undef; ok( 'ab' =~ /^a(?{7})(?:b(?{8}))?/\, 'ab =~ ab?' ); ok( $^R == 8\, '$^R == 8' );
$^R = undef; ok( 'ab' =~ /^a(?{9})b?(?{10})/\, 'ab =~ ab? (2)' ); ok( $^R == 10\, '$^R == 10' );
my @ar; ok( 'ab' =~ /^a(?{push @ar\,11})(?:b(?{push @ar\,12}))?/\, 'ab =~ ab?' ); ok( scalar(@ar) == 2\, 'nr pushed ok' ); ok( ($ar[0] == 11 and $ar[1] == 12)\, 'push contents ok' );
$^R = undef; ok( 'a' !~ /^a(?{13})b(?{14})/\, 'a !~ ab' ); ok( !defined $^R\, 'undef 3rd' );
@ar = (); ok( 'a' !~ /^a(?{push @ar\,15})b(?{push @ar\,16})/\, 'a !~ ab (push)' ); ok( scalar(@ar) == 0\, 'none pushed ok' );
@ar = (); ok( 'abc' !~ /^a(?{push @ar\,17})b(?{push @ar\,18})$/\, 'abc !~ ab$ (push)' ); ok( scalar(@ar) == 0\, 'none pushed ok' );
use vars '@var';
ok( 'ab' =~ /^a(?{push @var\,19})(?:b(?{push @var\,20}))?/\, 'ab =~ ab?' ); ok( scalar(@var) == 2\, 'nr pushed ok' ); ok( ($var[0] == 19 and $var[1] == 20)\, 'push contents ok' );
@var = (); ok( 'a' !~ /^a(?{push @var\,21})b(?{push @var\,22})/\, 'a !~ ab (push)' ); ok( scalar(@var) == 0\, 'none pushed ok' );
@var = (); ok( 'abc' !~ /^a(?{push @var\,23})b(?{push @var\,24})$/\, 'abc !~ ab$ (push)' ); ok( scalar(@var) == 0\, 'none pushed ok' ); __TEST_FILE_END__
david@landgren.net (via RT) wrote:
# New Ticket Created by david@landgren.net # Please include the string: [perl #32840] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32840 >
[...]
There do not appear to be any tests that check how $^R should behave. The following file is an attempt to improve matters.
Late night bad wording. There are indeed tests for $^R in t/op/pat.t but they don't exercise patterns with groupings.
Playing around some more\, the following match\, but $^R does not contain what is expected:
$^R = undef; ok( 'ac' =~ /^a(?{30})(?:b(?{31})|c(?{32}))?/\, 'ac =~ a(?:b|c)?' ); ok( $^R == 32\, '$^R == 32' );
$^R = undef; ok( 'abbb' =~ /^a(?{36})(?:b(?{37})|c(?{38}))+/\, 'abbbb =~ a(?:b|c)+' ); ok( $^R == 37\, '$^R == 37' ) or print "# \$^R=$^R\n";
David
The LAST_REGEXP_CODE_RESULT ($^R) variable appears to not be set in regexp matches involving a backreference. In the example below\, if you uncomment one of the two commented regexps and comment the '(foo|bar)\1+' regexp\, $^R will be properly set.
#! perl -w # $^R undefined on matches involving backreferences use strict;
print $^R\, "\n" if 'x foofoo y' =~ m{ # (foo) # $^R correctly set # (?:foo|bar)+ # $^R correctly set (foo|bar)\1+ # $^R undefined (?{ warn "Matched"\, defined $^N? " \<$^N>":""\, " and \$^R is about to be set to:\n"; "last regexp code result" }) }x
Hope that helps\, Dan Dascalescu
Attached patch fixes this bug.
It also includes a todo test for ticket 6006\, and some massaging of the test-reonly target and better test name defaulting.
Cheers\, Yves
Attached patch fixes this bug.
It also includes a todo test for ticket 6006\, and some massaging of the test-reonly target and better test name defaulting.
Cheers\, Yves
@demerphq - Status changed from 'new' to 'open'
On Fri\, 17 Nov 2006 20:09:31 +0100\, demerphq \demerphq@​gmail\.com wrote:
Done\, with some whitespace issues in #29308
I noted that regexec.c is very inconsistent in leading whitespace\, and also has many lines with trailing whitespace.
If it wasn't for Dave\, I would have fixed it :)
---------- Forwarded message ---------- From: yves orton via RT \bugs\-perl5@​bugs6\.perl\.org Date: Nov 17\, 2006 4:07 PM Subject: [perl #36909] $^R undefined on matches involving backreferences To: "of perl Ticket #36909\"" \<"OtherRecipients> Cc: perl5-porters@perl.org
Attached patch fixes this bug.
It also includes a todo test for ticket 6006\, and some massaging of the test-reonly target and better test name defaulting.
-- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using & porting perl 5.6.2\, 5.8.x\, 5.9.x on HP-UX 10.20\, 11.00\, 11.11\, & 11.23\, SuSE 10.0 & 10.1\, AIX 4.3 & 5.2\, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Sun Dec 05 03:50:40 2004\, david@landgren.net wrote:
david@landgren.net (via RT) wrote:
# New Ticket Created by david@landgren.net # Please include the string: [perl #32840] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32840 >
[...]
There do not appear to be any tests that check how $^R should behave. The following file is an attempt to improve matters.
Late night bad wording. There are indeed tests for $^R in t/op/pat.t but they don't exercise patterns with groupings.
Playing around some more\, the following match\, but $^R does not contain what is expected:
$^R = undef; ok( 'ac' =~ /^a(?{30})(?:b(?{31})|c(?{32}))?/\, 'ac =~ a(?:b|c)?' ); ok( $^R == 32\, '$^R == 32' );
$^R = undef; ok( 'abbb' =~ /^a(?{36})(?:b(?{37})|c(?{38}))+/\, 'abbbb =~ a(?:b|c)+' ); ok( $^R == 37\, '$^R == 37' ) or print "# \$^R=$^R\n";
This bug has been merged with 36909\, and has been resolved by patch #29308. The underlying issue was that CURLYX operands did a regcpblow() without taking measures to preserve $^R.
The attached patch updates the tests in t/op/rxcode.t to remove todo's and add additional tests from your ticket.
Cheers\, Yves
@demerphq - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#36909 (status was 'resolved')
Searchable as RT36909$