Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hashing of general objects was far too simple (fixes #20744) #20767

Merged
merged 2 commits into from
Feb 24, 2017
Merged

Conversation

StefanKarpinski
Copy link
Member

No description provided.

If we'd used `3h - object_id(x)` previously, the original issue
would never have come up since `hash(a, hash(b, hash(c, h)))`
wouldn't have produced `3A - 3B + 3C - h` but would instead have given
the value `27h -9A - 3B - C`, which is asymmetrical in `a` and `c`.
Passing the result to `hash_uint` fixes that issue since that function
is non-linear, but defense in depth, right? We may as well do the
same operations in such a way that the passed-through value gets the
most operations done on it.
@tkelman
Copy link
Contributor

tkelman commented Feb 23, 2017

dunno what our policy on hash-value stability is, but we should probably merge this before #20762 just in case

@JeffBezanson
Copy link
Member

The segfault on osx that appeared here might be fixed by #20777.

@tkelman
Copy link
Contributor

tkelman commented Feb 24, 2017

would it have anything to do with changing hash values, or is it preexisting and just coincidence?

@JeffBezanson
Copy link
Member

No, it's unrelated to hash values.

@tkelman tkelman merged commit 0dca594 into master Feb 24, 2017
@tkelman tkelman deleted the sk/hashfix branch February 24, 2017 08:30
@StefanKarpinski
Copy link
Member Author

dunno what our policy on hash-value stability is

We are allowed to change hash values any time we want to – code should not rely on them. In fact, I've considered whether we should randomize them from run to run.

@@ -55,7 +55,6 @@ end

## symbol & expression hashing ##

hash(x::Symbol, h::UInt) = 3*object_id(x) - h
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JeffBezanson: is it possible this line was added for performance since the hash(x::ANY, h::UInt) method doesn't specialize because of the ANY hint?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine it was either a #265-related bug (hash was pretty likely to run into bugs of that sort because of the fallback definition), or an oversight. object_id is also not specialized (and should just end up always inlined too)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, in your professional opinion, this should be safe to delete?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Looks like Tony already did though :)

@tkelman
Copy link
Contributor

tkelman commented Feb 24, 2017

code should not rely on them

is that documented at all? I don't think this is necessarily being followed.

@StefanKarpinski
Copy link
Member Author

It is not. But randomizing hash values should make it fairly clear 😈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants