This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Completely free hashes containing nulls
authorFather Chrysostomos <sprout@cpan.org>
Sun, 12 Jun 2011 21:46:44 +0000 (14:46 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Sun, 12 Jun 2011 21:46:44 +0000 (14:46 -0700)
commit7d6175ef71f6339fae97e36c1cdae9e4f47f74d0
treea222a3dd9597443219d01c6b5976128dd51a7f8f
parent30b0736d971c494432c032b4ca9fd2e8dcd31680
Completely free hashes containing nulls

This fixes a regression introduced since 5.14.0, by commit e0171a1a3.

The new Perl_hfree_next_entry function that that commit introduced
returns the value of the hash element, or NULL if there are none left.
If the value of the hash element is NULL, the two cases are indistin-
guishable.

Before e0171a1a3, all the hash code took null values into account.
mro_package_moved took advantage of that, stealing values out of a
hash and leaving it to the freeing code to delete the elements.

The two places that call Perl_hfree_next_entry (there was only one,
S_hfreeentries, with commit e0171a1a3, but the following commit,
104d7b699c, made sv_clear call it, too) were not accounting for NULL
values’ being returned, and could terminate early, resulting in mem-
ory leaks.

One could argue that the perl core should not be assigning nulls to
HeVAL, but HeVAL is part of the public API and there could be CPAN
code assigning NULL to it, too.

So the safest approach seems to be to modify Perl_hfree_next_entry’s
callers to check the number of keys and not to attribute a signifi-
cance to a returned NULL.
ext/XS-APItest/APItest.xs
ext/XS-APItest/t/hash.t
hv.c
sv.c