1N/A 'trying to delete a locked key' ); 1N/A 'trying to change a locked key' ); 1N/A 'trying to delete a key that doesnt exist' ); 1N/A ' individual key still readonly' ); 1N/Ais( $@, '', ' but can be deleted :(' ); 1N/A eval { %hash = ( wubble => 42 ) }; # we know this will bomb 1N/A is( $@, '', 'unlock_keys' ); 1N/A is( $@, sprintf("Hash has key 'bar' which is not in the new key ". 1N/A 'locked key never mentioned before should fail'); 1N/A 'previously locked place holders should also fail'); 1N/A 'previously locked place holders should fail'); 1N/A "undef values should not be misunderstood as placeholders"); 1N/A "undef values should not be misunderstood as placeholders (again)"); 1N/A # perl #18651 - tim@consultix-inc.com found a rather nasty data dependant 1N/A # bug whereby hash iterators could lose hash keys (and values, as the code 1N/A # is common) for restricted hashes. 1N/A # There should be no difference whether it is restricted or not 1N/A # Try setting all combinations of the 3 keys 1N/A # Yes. All these sorts are necessary. Even for "identical hashes" 1N/A # Because the data dependency of the test involves two of the strings 1N/A # colliding on the same bucket, so the iterator order (output of keys, 1N/A # values, each) depends on the addition order in the hash. And locking 1N/A # the keys of the hash involves behind the scenes key additions. 1N/A# Check clear works on locked empty hashes - SEGVs on 5.8.2. 1N/A ok(keys(%hash) == 0, 'clear empty lock_hash() hash'); 1N/A ok(keys(%hash) == 0, 'clear empty lock_keys() hash');