pad.c: Use &PL_sv_no for const pad names

Currently &PL_sv_undef as a pad name can indicate either a free slot
available for use by pad_alloc or a slot used by an op target (or,
under ithreads, a constant or GV).

Currently pad_alloc distinguishes between free slots and unnamed slots
based on whether the value in the pad has PADMY or PADTMP set.  If
neither is set, then the slot is free.  If either is set, the slot
is in use.

This makes it rather difficult to distinguish between constants stored
in the pad (under ithreads) and targets.  The latter need to be copied
when referenced, to give the impression that a new scalar is being
returned by an operator each time.  (So \"$a" has to return a refer-
ence to a new scalar each time, but \1 should return the same one.)
Also, constants are shared between recursion levels.  Currently, if
the value is marked READONLY or is a shared hash key scalar, it is
shared.  But targets can also me shared hash keys, resulting in bugs.

It also makes it impossible for the same constant to be shared by mul-
tiple pad slots, as freeing one const op will turn off the PADTMP flag
while the other slot still uses it, making the latter appear to be
free.  Hence a lot of copying occurs under ithreads.  (Actually, that
may not be true any more since 3b1c21fabed, as freed const ops swipe
their constants from the pad.  But right now, a lot of copying does
still happen.)

Also, XS modules may want to create const ops that return the same
mutable SV each time.  That is currently not possible without
various workarounds including custom ops and references.  (See
<https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.)

This commit changes pad_alloc and pad_free to use &PL_sv_no for con-
stants and updates other code to keep all tests passing.  Subsequent
commits will actually use that information to fix bugs.

This will probably break PadWalker, but I think it is an acceptable
trade-off.  The alternative would be to make PadnamePV forever more
complex than necessary, by giving it a special case for &PL_sv_no and
having it return NULL.

I gave PadnameLEN a special case for &PL_sv_undef, so it may appear
that I have simply shifted the complexity around.  But if pad names
stop being SVs, then this exception will simply disappear, since the
global &PL_padname_undef will have 0 in its length field.

1 files changed, 1 insertions, 1 deletions

diff --git a/pad.h b/pad.h
index 26e183ccd8..f6f3455148 100644
--- a/pad.h
+++ b/pad.h
@@ -290,7 +290,7 @@ Restore the old pad saved into the local variable opad by PAD_SAVE_LOCAL()
 #define PadMAX(pad)		AvFILLp(pad)
 
 #define PadnamePV(pn)		(SvPOKp(pn) ? SvPVX(pn) : NULL)
-#define PadnameLEN(pn)		SvCUR(pn)
+#define PadnameLEN(pn)		((pn) == &PL_sv_undef ? 0 : SvCUR(pn))
 #define PadnameUTF8(pn)		!!SvUTF8(pn)
 #define PadnameSV(pn)		pn
 #define PadnameIsOUR(pn)	!!SvPAD_OUR(pn)