Re: Regex backreference bug in recursion/thread (status & questions)

[Gurusamy Sarathy <gsar@ActiveState.com>]

On Mon, 31 Jan 2000 11:11:30 EST, Harry Wolfson wrote:
>Questions I have:
>  * Is it ok to have invocations/calls to an OPcode from _within_ another
>    Opcode node? I think this would be required inside regcomp.c:
>    Perl_pregcomp() to allocate scratchpad entries. But it might wreak
>    havoc with debugging tools like perl -Dx.

I think we should just allocate a single pad entry in op.c when the
PMOP gets created.  That single entry could be in the form of a
specialized SV/RV/AV (depending on what fits your needs) with other
things hanging off it.

The code that clones pads will need to know about this specialized
SV/RV/AV, but we already do this for GVs in the pad, so you could
just extend that.

>  * Would it make sense to do the actual memory allocation for the pad
>    values for startp[], etc at the very beginning of the regex execution
>    (I'm not _exactly_ sure where that is _all_ the time!). That way new
>    memory allocation would happen at every recursion or thread entry
>    point.

It should be possible to hold a reference to the target string and simply
point into it.  This avoids memory allocations.

>  * Would it make sense to use standard scratchpad api calls (padsv,
>    padav) to assign/retrieve values of startp[i], etc during the regex?

No, see above.  Once the pad entry is allocated during compilation
of the RE, the PMOP has an index into the pad that will always be
pointing at a valid SV* (which can hold anything you want).  You then
simply need to dig into this SV* to get at your data.


Sarathy
gsar@ActiveState.com

---

Follow-Ups from:

Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Harry Wolfson <HarryWolfson@LL.MIT.EDU>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---