Util.t revision 7c478bd95313f5f23a4c958a745db2134aa03244
BEGIN {
chdir 't';
}
}
use strict;
my @Exported_Funcs;
BEGIN {
);
}
}
lock_keys(%hash);
'lock_keys()');
'wide hex key' );
'trying to delete a locked key' );
'trying to change a locked key' );
eval { delete $hash{I_dont_exist} };
'trying to delete a key that doesnt exist' );
$hash{I_dont_exist} = 42;
' individual key still readonly' );
{
}
{
}
{
}
{
my %hash = ();
' locked');
}
{
}
{
}
{
}
like( $@, qr/^Attempt to access disallowed key 'I_DONT_EXIST' in a restricted hash/, 'locked %ENV');
{
my %hash;
$hash{interregnum} = 1.5;
like ($@,
'locked key never mentioned before should fail');
like ($@,
'previously locked place holders should also fail');
like ($@,
'previously locked place holders should fail');
"undef values should not be misunderstood as placeholders");
"undef values should not be misunderstood as placeholders (again)");
}
{
# perl #18651 - tim@consultix-inc.com found a rather nasty data dependant
# bug whereby hash iterators could lose hash keys (and values, as the code
# is common) for restricted hashes.
# There should be no difference whether it is restricted or not
# Try setting all combinations of the 3 keys
my @usekeys;
}
my %target;
$target{$k} = $v;
}
my $message
# Yes. All these sorts are necessary. Even for "identical hashes"
# Because the data dependency of the test involves two of the strings
# colliding on the same bucket, so the iterator order (output of keys,
# values, each) depends on the addition order in the hash. And locking
# the keys of the hash involves behind the scenes key additions.
}
}
}
}
}
# Check clear works on locked empty hashes - SEGVs on 5.8.2.
{
my %hash;
%hash = ();
}
{
my %hash;
%hash = ();
}
{
my $counter;
sub DESTROY {
--$counter;
}
sub new {
++$counter;
bless [], __PACKAGE__;
}
my %hash;
$hash{a} = $a;
undef $a;
%hash = ();
}
}