Pad variables without sigils?

diotalevi has asked for the wisdom of the Perl Monks concerning the following question:

In B::Deobfuscate - Deobfuscates symbol names I included a bit of code that runs $name =~ m{^(\W+)} or die "Invalid pad variable name $name"; my $sigil = $1; with the assumption that a pad variable always has a sigil and the sigil always matches /\W+/. Am I correct in making that assumption?

A note: I started out with the sigil as the first character until running into variables like *$foo where I had to keep the first two characters.

Comment on Pad variables without sigils? Select or Download Code

Replies are listed 'Best First'.
Re: Pad variables without sigils? by shotgunefx (Parson) on Mar 20, 2003 at 20:10 UTC
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."	[reply]
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.	[reply]
Re: Re^2: Pad variables without sigils? by shotgunefx (Parson) on Mar 20, 2003 at 21:05 UTC
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."	[reply]
Re: Re^2: Pad variables without sigils? by jand (Friar) on Mar 21, 2003 at 09:56 UTC
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.	[reply]