develooper Front page | perl.perl5.porters | Postings from April 2019

[perl #133970] BBC Commit 73b9584 breaks Roman::Unicode

From:
Karl Williamson via RT
Date:
April 22, 2019 00:39
Subject:
[perl #133970] BBC Commit 73b9584 breaks Roman::Unicode
Message ID:
rt-4.0.24-20057-1555893577-413.133970-15-0@perl.org
On Mon, 01 Apr 2019 16:34:33 -0700, tonyc wrote:
> On Sun, 31 Mar 2019 22:12:02 -0700, khw wrote:
> > On Sun, 31 Mar 2019 21:50:32 -0700, public@khwilliamson.com wrote:
> > > This is a bug report for perl from khw@khw-XPS-
> > > 8930.hsd1.co.comcast.net,
> > > generated with the help of perlbug 1.40 running under perl 5.26.1.
> > >
> > >
> > > -----------------------------------------------------------------
> > > The commit involved moving user-defined properties into core.  It
> > > is
> > > a
> > > separate issue from [perl #133860] which stems from the same
> > > commit,
> > > but
> > > the cause is actually that module inadvertently relying on a bug
> > > that
> > > this commit fixes.
> > > -----------------------------------------------------------------
> > > ---
> > > Flags:
> > >      category=core
> > >      severity=high
> > > ---
> >
> > I wrote this ticket with the system perl info instead of blead's.
> > But
> > it is actually irrelevant.
> >
> > Tony Cook++ tracked down the cause of this for me.  The stack needed
> > to pushed/popped around the call to the user-defined perl subroutine.
> > But then he wanted to see what the code this replaces does, and it
> > turns out it does several more things, which are similar to what the
> > code block regex code does, which is similar to what other places do
> > that call out to perl code.
> >
> > But not exact
> >
> > So is it a bug that for code blocks, there is no SAVEHINTS, or that
> > it
> > pushes (the undocumented) PERLSI_REQUIRE instead of (the
> > undocumented)
> > PERLSI_MAGIC?  And when should one use save_re_context()?  My guess
> > is
> > that SAVETMPS and FREETMPS are just niceties, but I don't know.
> >
> > None of this is obvious to me.  My guess is that the disparities in
> > calling things are actually bugs, and there should be a routine that
> > standardizes things, or at least documentation as to what to do.
> 
> They're required because you're doing something unusual - calling a
> perl sub while compiling a regular expression, *or* while matching[1]
> a regular expression.
> 
> For compile-time the SAVEHINTS is required so that changes to $^H or
> %^H don't result in lexical changes to the code being compiled (like
> turning off strict.)
> 
> The PUSHSTACK is needed because the code seems to be called from
> places that don't expect the stack to move.  I'm not sure exactly
> where that is in this case,  but it's an issue for various types of
> magic, eg.
> 
> pv = SvPV(somesv); /* can call get or overload magic */
> 
> but since that's the uncommon case it's best to optimize for magic not
> being called and put the magic code through the extra work of
> switching stacks.
> 
> The re_save_context() is more a run-time issue, so that the code you
> call doesn't modify $1 etc from underneath the caller.
> 
> All that said, I don't know that I would have realized this was
> necessary if I was writing the code.
> 
> Tony
> 
> [1] IIRC from a #p5p conversation a while back, the user sub can be
> called at runtime if it wasn't defined at regular expression compile-
> time.  It did appear to be called at runtime when I was debugging this
> issue.

The module now tests OK, so removing from blockers list.  I still need to write a test so keeping the ticket open
-- 
Karl Williamson

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



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About