[perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0 fromperlbrew

I have been thinking more about this lately.

On Sat Sep 08 05:01:55 2012, davem wrote:
> On Thu, Sep 06, 2012 at 03:09:44PM +0200, Leon Timmermans wrote:
> > I suspect we can provide a compatibility API that DWIMs on both
> > systems for most common usage patterns. It would still be a lot of
> > work, but it could easy such a transition.

E.g., a POPs that mortalizes the value when removing it from the stack, instead of freeing it.  It would still behave as expected, though it would be less efficient.

But having it work only for the ‘most common usage patterns’ is not acceptable, considering that all these macros have long been part of the public API.

> 
> If we have a refcounted stack, allowing existing XS subs to operate
> is fairly trivial. If an XS sub isn't marked as being 'refcounted stack
> aware', we simply memcopy the existing stack frame to make a new frame
> that contains the same SV pointers, but not refcount-imcremented.
> After the XSUB returns, we decrement the refcounts of the all the
> SVs in the original stack frame, then shuffle down the returned list,
> obliterating the original stack frame.

Yes, it can be made to work trivially for XSUBs.  But what about custom pp functions?  There seem to be more and more modules these days that use them, so we do need some way to have things work under both systems.

What is particularly difficult is that the same .xs file may have pp functions and XSUBs.  If POPs in an XSUB is old-style, it has to be defined as (*sp--).  pp functions have to use whichever stack perl itself uses, so that would be sv_2mortal(*sp--) on a newer perl.

How can we have POPs defined both ways in the same file?

Alternatively, if we use new macro names, then the pp function would have to use rPOPs on newer perls and POPs on older perls, which is a major API breakage.

Another thought I had is that a final pass when compiling a sub could wrap custom pp functions with a wrapper that copies things to a new stack and copies them back, just as we would do for XSUBs.  I don’t like it, but it may be the only way.  Though I still don’t think it would work for custom pp functions that wrap perl’s own pp functions.

I’m stuck.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=114372

• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Father Chrysostomos
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram
• [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0 fromperlbrew by Father Chrysostomos via RT
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram
• [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0 fromperlbrew by Father Chrysostomos via RT
• [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0 fromperlbrew by Father Chrysostomos via RT
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram
• Re: [perl #114372] Panic in pure-Perl code with vanilla perl-5.16.0from perlbrew by Zefram