Front page | perl.perl5.porters |
Postings from July 2009
On Mon, Jul 06, 2009 at 01:01:42AM +1000, Paul Fenwick wrote: > G'day Nicholas, > > Nicholas Clark wrote: > > > If I understand you correctly, the problem isn't that autodie needs to do > > more than %^H currently does. You don't just need something *lexical* to hang > > state in that can be introspected at compile time. > > > > You also need some mechanism to run a *dynamic* end-of-scope hook at compile > > time? > > Yes, this is exactly what autodie (and anything else using > B::Hooks::EndOfScope) needs. Right. So this is the feature that is actually wanted. Anything else is an implementation issue. Implementation issues: > > It was not reported at any time in the 3 years between when it was added to > > blead and when blead shipped as 5.10 > > > > This report of a possible bug is a bit late. > > I agree, it's very late! Until now, I don't think anyone noticed this was > actually a problem. What worked in 5.8.x continued to work in 5.10.x. > String evals are, well, not always the right way of doing things. As such, > the amount of code that used lexical triggers via %^H next to string evals > were very rare. > > Luckily... > > > This behaviour was never a documented part of the implementation. > > It IS NOT NOW. > > The 'perlpragma.pod' file, which talks about %^H in depth, says one > shouldn't store anything but simple strings and integers in %^H, because > anything else will get stringified. So the stringification *is* documented, > it's just the timing that isn't. Here is the relevant documentation for %^H, valid for all of 5.8.x =item %^H WARNING: This variable is strictly for internal use only. Its availability, behavior, and contents are subject to change without notice. The %^H hash provides the same scoping semantic as $^H. This makes it useful for implementation of lexically scoped pragmas. =cut > While I agree that using %^H in this way is an accidental feature, we can > fix the problem that has just been encountered by: > > 1) Upon string eval, we shallow copy %^H. We already do this. > 2) Immediately stringify the values in the copied %^H and store them. > We currently appear to do this much later (just before run-time?) > > With these changes, code relying upon ref-counts in %^H to trigger magic > will continue to work as they did in 5.8.x. Code using %^H to store Code relying on ANYTHING in %^H in 5.8.x is broken and wrong. I can't see how the documentation could be any clearer than the above. This isn't a philosophical position that we should have "rigidly defined areas of doubt and uncertainty". It's a simple practical problem. Perl 5 is pretty bloody hard to support right now. We try hard not to break stuff that is documented as behaving in some fashion, and stuff that is ambiguous in its documented behaviour. It will be impossible to do anything, if people come to expect that even the parts that are documented as "keep off. may change without warning" don't change. And heck, this wasn't even a change within a maint branch. This is a new stable release. CPAN authors need to get out of the habit of flouting the documentation. CPAN authors need to engage perl5-porters and *ask* for hooks that they believe to be missing, and we'll do our best to work out how. If it were trivial, I'd be contributing two new metrics to CPANTS 1: Uses any feature documented for internal use only. So that would be %^H pre 5.10.0, anything that defines PERL_CORE, etc 2: Directly or indirectly uses a module that uses an internal use feature. This isn't Perl we're talking about. The rewards for bending the rules are not uninitialised values warnings, autovivification and trappable exceptions. This is C. The rewards for bending the rules are SEGVs, undefined behaviour and CVEs. Nicholas ClarkThread Previous | Thread Next