Front page | perl.perl5.porters |
Postings from July 2012
On Thu, Jun 28, 2012 at 01:10:46PM -0500, Jesse Luehrs wrote:
> On Thu, Jun 28, 2012 at 03:42:52PM +0100, Zefram wrote:
> > It's failing in the cases where write() is called in list context and
> > exited via reified continuation. The item placed on the stack before
> > calling write() is getting lost. Don't know whose fault this is yet,
> > but more likely the module.
>
> This may have something to do with the POPs I had to add to the
> beginning of pp_leavewrite - it seems like the compiled format itself is
> leaving an extra value on the stack, but I couldn't track down where, so
> I ended up just cleaning it up in leavewrite, since that didn't seem to
> cause any issues. This makes calls to write() behave properly in the
> normal case, but there might still be some incorrect stack manipulation
> going on if you're interrupting things partway through, like
> Scope::Escape seems to do.
A format declaration like
@<< @<<
$a, $b
@<< @<<
$c, $d
is compiled into a sub-like thingy that looks
like
sub foo {
formline '@<< @<<', $a, $b;
formline '@<< @<<', $c, $c;
}
There is a nextstate op after the earlier formlines, which clears
any junk from the stack, but not after the last formline. So at the point
of entry to leavewrite, what's on the stack is what the formline left on
it (typically SV_YES).
Its possible (but I don't know and haven't looked) that the last thing
in the format 'sub' may not always be a formline but something else, so
what's left on the stack might not always be a single item.
If that's the case, then rather than doing a POPs, do what pp_nextstate
does instead:
PL_stack_sp = PL_stack_base + cxstack[cxstack_ix].blk_oldsp;
Whether this fixes the issue with Zefram's module, I don't know.
--
I thought I was wrong once, but I was mistaken.
Thread Previous
|
Thread Next