Fix hash ordering dependency in DBM_Filter/t/int32.t

Under the filtering rules in place undef() and "" and 0 map to a
packed representation of 0.

In the StoreData call we pass in an anonymous perl (untied) hash
containing an "undef" key (which is actually treated as "") with a
value of undef(), along with a key 0 with a value of 1. This hash
will store both values as distinct key/value pairs.

When this hash is used to set up the *tied* %h1 hash both the "" key
and the 0 key will be converted into the same packed value "\0\0\0\0",
which means that whichever is last in the each() of the input hashref
will be the one stored in %h1.

This means the test breaks if we change the PL_hash_seed or the hash
implementation in such a way that "" comes before 0 in the keys of
the hash.

This patch changes the input test hash to verify that undef() => 1 is
treated the same as 0 => 1, and eliminates the potential key collision.
The reason this test was reliable in the wild is that pretty well all
perls use a 0 hash seed and the same hash function.

This test probably would have broken in other enviornments as well.

diff --git a/lib/DBM_Filter/t/int32.t b/lib/DBM_Filter/t/int32.t
index 96d4d9e..a74d49d 100644 (file)
--- a/lib/DBM_Filter/t/int32.t
+++ b/lib/DBM_Filter/t/int32.t
@@ -55,9 +55,8 @@ is $@, '', "push an 'int32' filter" ;
     no warnings 'uninitialized';
     StoreData(\%h1,
        {       
-               undef() => undef(),
                "400"   => "500",
-               0       => 1,
+                undef()        => 1,
                1       => 0,
                -47     => -6,
        });