Jeff Key

It works on my machine

Sponsors

My Job

My stuff

Old stuff

Useful Stuff

GetHashCode() != GetHashCode()

Many people take object hash codes for granted and don't understand the sometimes important role they play.  Brad Abrams takes a moment to explain some changes that will be coming our way in a future version of the framework.

Posted: Sep 30 2003, 11:19 PM by jeffreykey | with 3 comment(s)
Filed under: ,

Comments

Oleg Tkachenko said:

Your title is wrong, GetHashCode()always equals to GetHashCode().
But the point is that if a!=b, below may be true:
a.GetHashCode() == b.GetHashCode()
# October 1, 2003 2:47 AM

Jeff Key said:

I was referring to the GetHashCode()s in the current (1.0, 1.1) frameworks vs the next framework (1.2?). a.GetHashCode() will be return a different value in v.Next than it does now.
# October 1, 2003 8:36 AM

damien morton said:

There are some attacks based on causing lots of hashcode collisions. These are called algorithmic complexity attacks.

The defene against them is to "key" the hash function so that between executions, or even between hashtable resizes, the hashcode returned is unpredictable. It will still fullfill the contract that if a == b then a.GetHashCode() == b.GetHashCode().

Basically, relying on other properties of GetHashCode is a mistake. Frankly, the object identity that GetHashCode returns is also a mistake; they could have at least incremented their counter by some big number instead of 1, or multiply their dequence number by a large prime before returning Object.GetHashCode().
# November 14, 2003 5:58 PM