[Expat-discuss] XML_SetHashSalt(p, 0) semantics

[Karl Waclawek]

The comment in the patch indicates that the new defined  value (XML_DISABLE_HASH_RANDOMIZATION ) disables hash randomization.

I guess your point is to single out a specific value for doing this, however, this still requires the programmer to pass that same value every time the parser is used.
The same effect can be achieved with any other value, as long as you never change it. The only difference would be that the hash salt would be different from old Expat versions.

I would think that this could actually cloud the issue as the programmer might expect that this is the only value that disables hash randomization.

In any case, no-one should rely on the hash table implementation within Expat - except hackers ;-) 
Furthermore, there never was  a promise that the hash function used in Expat would stay the same, and changing it would not have been considered a breaking change.

I am not too concerned about leaving it as it is.

Karl


-----Original Message-----
From: David Malcolm [mailto:dmalcolm at redhat.com] 
Sent: May-25-12 1:44 PM
To: Fred Drake
Cc: karl at waclawek.net; Joe Orton; Kurt Seifried; Tomas Hoger; expat-discuss at libexpat.org
Subject: Re: [Expat-discuss] XML_SetHashSalt(p, 0) semantics

On Mon, 2012-05-14 at 16:01 -0400, Fred Drake wrote:
> On Mon, May 14, 2012 at 12:31 PM, Karl Waclawek <karl at waclawek.net> wrote:
> > One could also say that it is a good thing that test cases are forced to be fixed....
> 
> Definitely.
> 
> +1 to fixing the documentation.  Relying on the order of entries in a
> hash is a really bad thing, and they shouldn't be difficult to fix.
> 
> Whatever sentinel value is used, it should be provided as a #define.
> I don't expect it to really matter whether it's 0 or 0xFFFFFFFF, but 
> changing it would be an API breakage at this point.

How about something like the attached patch (compiles, but not tested)