develooper Front page | perl.perl5.porters | Postings from January 2018

Re: Captured lexicals stolen from outer scope's pad

Thread Previous
Paul "LeoNerd" Evans
January 22, 2018 04:49
Re: Captured lexicals stolen from outer scope's pad
Message ID:
On Mon, 22 Jan 2018 03:29:26 +0000
"Paul \"LeoNerd\" Evans" <> wrote:

> So, on to my questions:
>  1) Why does perl decide to steal the AV from the outside's pad and
>     replace it there with an empty stale AV?

Turns out - there isn't any code for that. The outside's pad got tidied
up somehow because it was finished, and its SVs replaced by empty
stale-marked ones. The fact this hadn't turned up in unit testing
of F::AA until now was that I hadn't thought of trying to capture
lexicals from inside a scope that I then ended before running the test
against some named functions from it. I've now added such a test.

> Alternatively, just before I call cv_clone() I could just walk the
> padlist looking for PadnameOUTER slots whose SV pointers in the
> pad and the corresponding outside slot don't agree, and put them back
> into place again. But not knowing the reasons why perl does this
> in the first place, I wasn't sure if that would be safe.

I'm now happier with the reason why, so this is my current workaround.
It does sometimes invoke some

  Variable "$FOO" is not available at ...

warnings, which I've found I can suppress by temporarily adjusting
CvDEPTH(CvOUTSIDE(curcv)) to 1 if it's currently 0. That only seems to
matter to the captured PadnameOUTER slots, which in any case I fix up
myself afterwards, so it seems to work out OK in practice.

Paul "LeoNerd" Evans      |  |

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