in reply to Pad variables without sigils?

No. There's other stuff in there. I noticed with PadWalker before ( I was working on a poke_my) there was other scratch stuff in there besides lexicals.
update
It wasn't with Padwalker, I passed pad back to Perl and was iterating it.

-Lee

"To be civilized is to deny one's nature."

Replies are listed 'Best First'.
Re^2: Pad variables without sigils?
by diotalevi (Canon) on Mar 20, 2003 at 20:58 UTC

    Hmmm. If you or anyone knows of any constructions that access these things I'd be interested. I'm still not sure there's anything that I'll encounter in the optree that touches them.

      No idea what is put there. I believe it's just scratch space for certain operation but what makes or uses those SVs I have no idea.
      Update
      I went looking through my poke_my notes and refreshed my memory. My understanding is that the other stuff in the pad is indeed scratch space for opcodes.

      From perlguts
      A scratchpad keeps SVs which are lexicals for the current unit and are targets for opcodes. One can deduce that an SV lives on a scratchpad by looking on its flags: lexicals have SVs_PADMY set, and targets have SVs_PADTMP set.

      -Lee

      "To be civilized is to deny one's nature."
      I don't remember the details, but some ops store state data in the TARG field (e.g. regex opcodes). When Perl is compiled with ithreads support, the opcode tree is shared between interpreters, so storing data in the optree creates concurrency problems. In that case the SV* is moved to an unnamed scratchpad entry and the TARG field contains an index into the pad instead of the SV* itself.