Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

DAVEM TPF bug-grant report #113

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


davem at iabyn

May 6, 2012, 1:06 PM

Post #1 of 4 (112 views)
Permalink
DAVEM TPF bug-grant report #113

Spent the week intermittently continuing to work on the code-calling
aspect of /(?{})/. I've managed to get it working with (an enhanced)
MULTICALL with all tests passing; although it needs more tests and work.

In particular, things like /(?{die/next/last/caller})/ no longer SEGV.

I took the Executive Decision that the only sane semantics for regex code
blocks were to treat them similarly to sort blocks, tie methods, %SIG
handlers etc, where a new stack is pushed, 'next', 'goto' etc can't
see anything external to that block, and 'return' returns from the code
block, not any enclosing sub.

Report for period 2012/04/30 to 2012/05/06 inclusive

SUMMARY
-------

Effort (HH::MM):

0:00 diagnosing bugs
9:55 fixing bugs
0:00 reviewing other people's bug fixes
0:00 reviewing ticket histories
0:00 review the ticket queue (triage)
-----
9:55 TOTAL

Numbers of tickets closed:

0 tickets closed that have been worked on
0 tickets closed related to bugs that have been fixed
0 tickets closed that were reviewed but not worked on (triage)
-----
0 TOTAL


DETAIL
------

[perl #34161] METABUG - (?{...}) and (??{...}) regexp issues

2012/05/02 0:30 fix

2012/05/04 1:35 fix

2012/05/05 2:30 fix

2012/05/06 5:20 fix


--
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
-- Woody Allen


sprout at cpan

May 10, 2012, 12:43 PM

Post #2 of 4 (105 views)
Permalink
Re: DAVEM TPF bug-grant report #113 [In reply to]

Re: DAVEM TPF bug-grant report #113

Dave Mitchell said:
> .../(?{})/....
> I took the Executive Decision that...'return' returns from the code
> block, not any enclosing sub.

I find that counterintuitive. Could you not make (?{return}) an
error, at least for now, so we still have a chance to change it later?


davem at iabyn

May 11, 2012, 3:02 AM

Post #3 of 4 (103 views)
Permalink
Re: DAVEM TPF bug-grant report #113 [In reply to]

On Thu, May 10, 2012 at 07:43:14PM -0000, Father Chrysostomos wrote:
> Re: DAVEM TPF bug-grant report #113
>
> Dave Mitchell said:
> > .../(?{})/....
> > I took the Executive Decision that...'return' returns from the code
> > block, not any enclosing sub.
>
> I find that counterintuitive. Could you not make (?{return}) an
> error, at least for now, so we still have a chance to change it later?

Well, it behaves the same way as sort, and indeed uses the same mechanism:

$ ./perl -le 'print sort { return $a <=> $b } 3,2,1'
123
$

So any dieing would have to be special-cased with an extra context flag
which is handled in the stack unwinding code.

But I can't see any realistic way that return could ever return from the
enclosing sub (if any). It suffers from the same issue as tie and %SIG
handlers, in that it's run within a new RUNOPS loop, and you'd need to do
a longjmp out of that loop and any calling functions (such as S_regmatch
etc) back to the parent RUNOPS loop; but nothing has set up a setjmp to
catch that. In addition, the regex engine can now be called directly from
XS code, so you have no way of knowing what's between you and the original
RUNOPS loop on the C stack.

--
I thought I was wrong once, but I was mistaken.


sprout at cpan

May 13, 2012, 10:06 PM

Post #4 of 4 (98 views)
Permalink
Re: DAVEM TPF bug-grant report #113 [In reply to]

On May 11, 2012, at 3:02 AM, Dave Mitchell wrote:

> On Thu, May 10, 2012 at 07:43:14PM -0000, Father Chrysostomos wrote:
>> Re: DAVEM TPF bug-grant report #113
>>
>> Dave Mitchell said:
>>> .../(?{})/....
>>> I took the Executive Decision that...'return' returns from the code
>>> block, not any enclosing sub.
>>
>> I find that counterintuitive. Could you not make (?{return}) an
>> error, at least for now, so we still have a chance to change it later?
>
> Well, it behaves the same way as sort, and indeed uses the same mechanism:
>
> $ ./perl -le 'print sort { return $a <=> $b } 3,2,1'
> 123
> $
>
> So any dieing would have to be special-cased with an extra context flag
> which is handled in the stack unwinding code.
>
> But I can't see any realistic way that return could ever return from the
> enclosing sub (if any). It suffers from the same issue as tie and %SIG
> handlers, in that it's run within a new RUNOPS loop, and you'd need to do
> a longjmp out of that loop and any calling functions (such as S_regmatch
> etc) back to the parent RUNOPS loop; but nothing has set up a setjmp to
> catch that.

Then why canít the runloop set up a setjmp?

> In addition, the regex engine can now be called directly from
> XS code, so you have no way of knowing what's between you and the original
> RUNOPS loop on the C stack.

If dying is acceptable in that case, then it seems odd that next/last/goto is not, from the point of view of a Perl user.

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.