develooper Front page | perl.perl5.porters | Postings from March 2007

[PATCH] Resolve PL_curpm issues with (??{}) and fix corruption of match results when pattern is a qr.

Thread Next
From:
demerphq
Date:
March 21, 2007 02:39
Subject:
[PATCH] Resolve PL_curpm issues with (??{}) and fix corruption of match results when pattern is a qr.
Message ID:
9b18b3110703210239x540f5ad9mdb41c2ea6229ac31@mail.gmail.com
Attached patch is a hacky workaround for the fact that match results
are stored in the regexp structure. This was not a problem before qr//
because a match could only be used in a single context. However with
qr// this is not true. Its possible for a single qr// to be PL_curpm
in two seperate scopes with different match results simultaneously,
which the current design simply doesnt allow.

It also fixes a problem with PL_curpm not being set properly before
executing code inside of a (?{}) and (??{}) construct. (This is a
recent issue related to the derecursivization of the regex engine.)

The solution is that when using a qr// a lightweight copy of the
regexp struct is made, and then the matching is done using that. See
Perl_reg_temp_copy() for details of the lightweight copy procedure.

One reprecussion of this patch is that its no longer possible to get
access to the match results in a qr// because the qr// never gets
match results as its just a template for the lightweight copy.

Long term this all needs to be restructured so that match results data
is stored in a different structure which contains a pointer to the
regexp that generated it.

The instead of taking a copy of the regexp structure we would just
create a new regexp result object.

Anyway, for now this should do, if we want the more indepth solution
ill have to find some time to do it and we will need a fair amount of
time to test it, as it will be a very intrusive patch.

Patch requires a make regen after application.

This will probably break some of the work done by Avar and Audreyt in
terms of new engines, as will the proper solution later on. Sigh. But
i cant see any way around that, and fixing this properly for 5.10
would be a big deal and delay things quite a bit.

End result of this however is that

  /.../o

will become faster to use than

  /$qr/

in the future, although only moderately so. Not that much data needs
to be copied.

Cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"


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