Personally, after all the work I have done over the past 25 years to make
mod_perl what it is today, I could care less about making it easy for other
people to avoid patching source code to perl itself.
If you don't like the performance gains of using :Sealed subroutines on
your mod_perl
On Feb 14, 2024, at 2:27 PM, Joe Schaefer wrote:
> sealed.pm is really only necessary in a mod_perl context. And really it only
> matters if you are using subrequests to reenter :Sealed handlers. Otherwise
> I don't see the point of the exercise.
Well, I suppose one point of the exercise
sealed.pm is really only necessary in a mod_perl context. And really it
only matters if you are using subrequests to reenter :Sealed handlers.
Otherwise I don't see the point of the exercise.
On Wed, Feb 14, 2024 at 2:25 PM Joe Schaefer wrote:
> Why would there be? It only impacts :sealed subs,
Why would there be? It only impacts :sealed subs, which is not bundled with
Perl.
On Wed, Feb 14, 2024 at 2:24 PM Ed Sabol wrote:
> On Feb 14, 2024, at 12:18 PM, Joe Schaefer wrote:
> > pad.c will segfault with an out-of-bounds memory access at line 2460 of
> pad.c.
>
> Is there a Perl/perl5
On Feb 14, 2024, at 12:18 PM, Joe Schaefer wrote:
> pad.c will segfault with an out-of-bounds memory access at line 2460 of pad.c.
Is there a Perl/perl5 GitHub issue or pull request for this?
Regards,
Ed
pad.c will segfault with an out-of-bounds memory access at line 2460 of
pad.c. If you are willing to recompile perl with a dirty hotfix, there is
one mentioned near the bottom of this page:
https://blogs.sunstarsys.com/joe/perl7-sealed-lexicals.html.en.gz
--
Joe Schaefer, Ph.D.
