summaryrefslogtreecommitdiff
path: root/mg.c
diff options
context:
space:
mode:
authorFather Chrysostomos <sprout@cpan.org>2012-01-08 12:30:45 -0800
committerFather Chrysostomos <sprout@cpan.org>2012-01-08 12:43:26 -0800
commit4c13be3f693f771014c91d74065ab1f92b583490 (patch)
tree3ecaf8b95642e35fdaeb30ad8a0b83bf25c64eeb /mg.c
parent4806b7ebf30d3ffe5c6af8f2c3b9f3e779979024 (diff)
downloadperl-4c13be3f693f771014c91d74065ab1f92b583490.tar.gz
[perl #67490] Don’t call DELETE on scalar-tied elem
This little snippet: sub TIESCALAR{bless[]} sub STORE{} tie $^H{foo}, ''; $^H{foo} = 1; delete $^H{foo}; dies with ‘Can't locate object method "DELETE"...’. This bug was introduced for %^H by commit b3ca2e834c, but it is actu- ally an older bug that already affected %ENV before that. Clear-magic on a scalar is only called when it is an element of a mag- ical aggregate. For hashes, this clear-magic is called whenever the hash itself is RMAGICAL. Tied scalars and elements of tied aggregates use the same magic vta- ble, under the assumption that mg_clear will never be called on a tied scalar. That assumption is wrong. Commit b3ca2e834c is the one that made %^H magical, which is why it caused this problem for %^H. The obvious solution, giving tied scalars their own vtable, is not as simple as it sounds, because then tied scalars are no longer RMAGICAL, and at least some of the tie code assumes that they are. So the easiest fix is to skip the DELETE call in Perl_magic_clearpack if the type of magic is PERL_MAGIC_tiedscalar.
Diffstat (limited to 'mg.c')
-rw-r--r--mg.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/mg.c b/mg.c
index 54a41f0335..b72c74afbf 100644
--- a/mg.c
+++ b/mg.c
@@ -1908,6 +1908,7 @@ Perl_magic_clearpack(pTHX_ SV *sv, MAGIC *mg)
{
PERL_ARGS_ASSERT_MAGIC_CLEARPACK;
+ if (mg->mg_type == PERL_MAGIC_tiedscalar) return 0;
return magic_methpack(sv,mg,"DELETE");
}