Plan B for fixing 5.8.2 binary API

[Chip Salzenberg <chip@debian.org>]

According to Nicholas Clark:
> On Thu, Oct 09, 2003 at 10:41:34PM -0400, Chip Salzenberg wrote:
> >   3. Add (or xor or whatever) PL_new_hash_seed with the user-provided
> >      hash value *inside* the functions that use hashes, *not* outside them.
> 
> I think that it has to be "whatever" [...]
> I believe that information we have to play with is
>   1: 32 bit PERL_HASH value
>   2: key length
>   3: per run 32 bit random seed
> How can we generate a new value out of that at little cost?

OK, that was eye-opening.  Let's be pessimistic and assume that we can't
use my initial approach -- at least, not without significant theoretical
doubts about its security.  How about an alternative approach:

 1. Rename all functions that accept key hashes. For argument's sake,
    let's say we append "_seed" to their names.  So the current function
    named "hv_fetch_ent" becomes "hv_fetch_ent_seed".

 2. Hide this renaming behind a macro so that it is invisible to all of
    Perl's internals and to any XS code recompiled from 5.8.2 forward:

      #define hv_fetch_ent hv_fetch_ent_seed

 3. Define stub functions with the old names that accept and *ignore* the
    provided string hash, recalculating it and calling the _seed versions.
    This is a speed hit for some usage, but it's safe and binary-compatible.

Advantages:

  * Maintains full hash seed functionality w/o risky new algorithms.
  * Achieves binary compatibility back to 5.8.0.
  * Whatever speed penalty exists is cured with a simple recompilation.

Disadvantages:

  * Crufty code hack.  (Nothing new to Perl of course.)
  * Speed penalty for the few XS modules that use PERL_HASH() and
    which will not have been recompiled with 5.8.2.

Comments?
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K