develooper Front page | perl.perl5.porters | Postings from September 2003

Re: [PATCH?] Re: [perl #23576] valgrind errors for /(?{})/ in t/op/pat.t

Thread Previous | Thread Next
From:
hv
Date:
September 18, 2003 17:21
Subject:
Re: [PATCH?] Re: [perl #23576] valgrind errors for /(?{})/ in t/op/pat.t
Message ID:
200309190026.h8J0QQF07307@zen.crypt.org
Dave Mitchell <davem@fdgroup.com> wrote:
:Perl_sv_compile_2op() is trying to distinguish between compile-time and
:runtime behaviour, ie between
:
:    /(?{1})/
:and
:    $x = '(?{1})'; /$x/
:
:with the following line (written by me a few months ago):
:
:    /* we get here either during compilation, or via pp_regcomp at runtime */
:    runtime = PL_op && (PL_op->op_type == OP_REGCOMP);
:
:But in the compoile-time case, PL_op isn't guaranteed to be pointing to
:anything sensible (eg in the test code that valgrind is complaining about,
:it happens to point to a recently-freed op).
:
:Does anyone know of a safe way that I can distinguish between compile-time
:and run-time calls to sv_compile_2op() ?

I'm not sure that I understand there _is_ a difference: I mean, both
of those could be wrapped in an either an eval or a BEGIN block, right?

Are you just trying to determine from which of two places sv_compile_2op()
is being called? If so that seems likely to be a bad idea: that function
is dcoumented as a public API function. If it needs to select its
behaviour based on the caller's context then it should probably be
replaced with a "..._flags" function that allows the caller explicitly
to specify the context.

I haven't looked at the code, but my gut feeling is that sv_compile_2op
should not be looking at PL_op at all. Perhaps the better solution would
be to remove the responsibility for this to the relevant caller.

Hugo

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