develooper Front page | perl.perl5.porters | Postings from February 2023

Re: PERL_RC_STACK branch: first cut

Thread Previous | Thread Next
Paul "LeoNerd" Evans
February 28, 2023 13:05
Re: PERL_RC_STACK branch: first cut
Message ID:
Overall: This is some excellent stuff here. I am most looking forward
to seeing it land.

Pace-wise I agree with other comments that it might be best to save it
for a 5.39.0 rather than try to squeeze it into 5.37 at this late stage
- especially since it might have unforseen interactions with my recent
feature-class work. I know I do some slightly funky things with the
stacks in there, so it would be good not to do a "Solaris 10" [1]

[1]: Solaris 10 launched with three big new features - Zones, ZFS and
     DTrace. They were all merged so late in the development process
     that none of them was aware of the others. When 10 launched, zones
     could not use ZFS as their root filesystem, dtrace could not cross
     zone boundaries, and ZFS operations did not appear in dtrace
     output. Fun times.

On Sun, 26 Feb 2023 16:06:12 +0000
Dave Mitchell <> wrote:

> The first 16 commits in this branch are generic fixups for things I
> spotted while working on this branch, and could be committed even if
> this branch was rejected overall.

It sounds like Yves is already on the ball on that, but yes if they're
smallish tidying up the could go in first.

> which should be required reading for any core hackers. I've cut and
> pasted it at the bottom of this email for convenience.

You actually pasted it twice - once in the middle of the other ;) It's
not *quite* as scary-long as the email size makes it look.

> The whole C<dSP> thing harks back to the days before decent optimising
> compilers. It was always error-prone, e.g. if you forgot a C<PUTBACK>
> or C<SPAGAIN>. The new API always just accesses C<PL_stack_sp>
> directly. In fact the first step of upgrading a PP function is always
> to remove the C<dSP> declaration. This has the happy side effect that
> any old-style macros left in the pp function which implicitly use
> C<sp> will become compile errors. The existence of a C<dSP> somewhere
> in core is a good sign that that function still needs updating.

OMG +1 to this alone. If nothing else, getting rid of that entire dSP
/ PUTBACK / SPAGAIN dance would make me much happy. I've now lost count
the number of times I've had a hard-to-trace bug that turned out to be
a missing SPAGAIN that *usually* didn't matter, so hunting it down was
very unreliable. It would be great not to have to worry about these any

Paul "LeoNerd" Evans      |  |

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