develooper Front page | perl.perl5.porters | Postings from January 2017

Re: [perl #130561] Coredump in Perl_re_op_compile

Thread Previous | Thread Next
January 27, 2017 16:01
Re: [perl #130561] Coredump in Perl_re_op_compile
Message ID:
On 27 January 2017 at 16:15, Hugo van der Sanden via RT
<> wrote:
> On Fri, 27 Jan 2017 01:26:03 -0800, demerphq wrote:
>> Instead of converting the impossible construct into an OPFAIL, we can
>> inject an OPFAIL in *front* of the impossible construct.
> Cool, I like.
>> This patch would have been easier if S_reginsert() documented that it is
>> the callers responsibility to properly set up the NEXT_OFF() of the inserted
>> node (if the node has a NEXT_OFF())
> Should it be setting that only if PASS2? I didn't think we were supposed to write into the node during sizing.

Good catch. Fix is testing and will be pushed shortly.

> (and earlier)
> hv> So for now I'm going to look instead whether I can make it less dangerous to
> hv> miss RExC_recurse entries, that feels like the surer (and more useful) target.
> dq> That wont work either.
> Just to clarify: I assume you mean "that won't be enough to let us remove the ops".

Yes, correct. "foo"=~/(foo){1,0}|(?1)/ should match (assuming we allow
the pattern at all).

> I'm not entirely sure that I have a use case, but what I had in mind was to modify the fixup loop as in your "this GOSUB may have been optimized away" change, but combine it with a regexec-time check & panic should we see a GOSUB that hasn't had its target set (which requires inventing a way to flag that). Failing that, we should at least have an assert at the point of fixup, for a clea[nr]er failure mode.

If we do this in debug mode only then I see no harm. Right now I see
no immediate need, but your point about cleaner failure modes for
future developers is compelling. Can I leave that part to you?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About