Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the autobox CPAN distribution.

Report information
The Basics
Id: 65214
Status: resolved
Priority: 0/
Queue: autobox

People
Owner: CHOCOLATE [...] cpan.org
Requestors: ribasushi [...] leporine.io
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: 2.72



Subject: Weirdness in $^H handling
From #p5p yesterday: <Zefram> in older Perl versions you needed to set bit 17 in $^H in order to maintain scoping of %^H <ribasushi> Zefram: so why in different modules do I see a different mask (which I presume always includes bit 17) <ribasushi> right it was autobox which has "$^H |= 0x120000; # set HINT_LOCALIZE_HH + an unused bit to work around a %^H bug" <ribasushi> and B::Hooks::EndOfScope with "$^H |= 0x020000;" <ribasushi> Zefram: ok... so autobox sets bit 17, but also sets bit 20, which according to perl.h is HINT_RE_TAINT <ribasushi> Zefram: could this be a bug in itself? <Zefram> ribasushi: setting HINT_RE_TAINT in autobox sounds like a bug Could you explain your motivation behind using HINT_RE_TAINT? The comment mentions something about a bug, but there is no SCM history to look at :(
Thanks for spotting this. Show quoted text
> Could you explain your motivation behind using HINT_RE_TAINT?
I thought it was unused for some bizarre reason. I probably concluded that via debug statements rather than looking at the source. Mea culpa. The next release will use a genuinely unused bit to workaround the %^H scoping bug. There's more info on that bug in autobox.xs, by the way: XXX this is fixed in #33311: http://www.nntp.perl.org/group/perl.perl5.porters/2008/02/msg134131.html (This issue is also fixed/worked around by my Devel::Pragma module and Zefram's Lexical::SealRequireHints.) Show quoted text
> there is no SCM history to look at
It's (belatedly) on GitHub: https://github.com/chocolateboy/autobox/ Eventually, I'll switch autobox to using "Modern Perl Pragma" helper modules (B::Hooks::OP::Check, B::Hooks::EndOfScope &c.) and get rid of the "unused bit" hack, but I don't have time for that at the moment. Thanks again, chocolateboy.
On Fri Jan 28 07:15:20 2011, CHOCOLATE wrote: Show quoted text
> Thanks for spotting this. > > Eventually, I'll switch autobox to using "Modern Perl Pragma" helper > modules (B::Hooks::OP::Check, B::Hooks::EndOfScope &c.) and get rid of > the "unused bit" hack, but I don't have time for that at the moment. >
(sorry for re-opening the ticket) What is the actual motivation behind the "extra" bit setting? I tried to look around your code, it doesn't seem obvious how the extra bit helps with leakage of %^H. Zefram (the author of Lexical::SealRequireHints not less) couldn't explain your motivation either. So could you please enlighten the masses? :)
On Sat Jan 29 09:53:32 2011, RIBASUSHI wrote: Show quoted text
> On Fri Jan 28 07:15:20 2011, CHOCOLATE wrote:
> > Thanks for spotting this. > > > > Eventually, I'll switch autobox to using "Modern Perl Pragma" helper > > modules (B::Hooks::OP::Check, B::Hooks::EndOfScope &c.) and get rid of > > the "unused bit" hack, but I don't have time for that at the moment. > >
> > (sorry for re-opening the ticket) > > What is the actual motivation behind the "extra" bit setting? I tried to > look around your code, it doesn't seem obvious how the extra bit helps > with leakage of %^H. Zefram (the author of Lexical::SealRequireHints not > less) couldn't explain your motivation either. So could you please > enlighten the masses? :)
Prior to perl #33311, values in %^H (i.e. the HV slot of PL_hintgv) leaked (i.e. weren't cleared/restored) across file boundaries (i.e. across require()s), but $^H (PL_hints) didn't/doesn't i.e. it's cleared/restored correctly across file boundaries. Without that, it's impossible to guard against autobox leaking across file boundaries. autobox is a BF (Before Florian :-) module that doesn't (yet) take advantage of modern Perl tools to work around that, so it uses a hack. Please see the 1.03 commit on GitHub (where the workaround was introduced) and grep the abovementioned modules/documentation for 33311 for more details: git diff 1773b79e0943a36f97ce9ea8d18bffe509079e52^1..1773b79e0943a36f97ce9ea8d18bffe509079e52
Show quoted text
> Without that, it's impossible to > guard against autobox leaking across > file boundaries.
And by "leak", I mean: if autobox is enabled in a scope in a.pl it would leak into B.pm if B.pm was required at compile-time from that a.pl scope. autobox needs a way to determine if it should modify method lookup OPs (i.e. it needs to test if it's enabled), and %^H didn't provide that (and still doesn't by default prior to 33311). The net result was that enabling autobox in a.pl would also enable it in B.pm (i.e. "leak"). The $^H (PL_hints) hack fixed that. Instead of relying on the broken %^H semantics, autobox accesses (one bit of) $^H which is correctly cleared/restored before/after a require(). Or, to put it another way, $^H understands that require() creates a new scope, but %^H didn't prior to #33311.
P.S. Please re-open this ticket if you have any more questions. Or re-open it anyway. I should probably keep it open as a reminder to remove the hack. But I won't get round to that without high-calibre (AKA awesome) nagging, which you're amply providing. :-)