[webkit-reviews] review granted: [Bug 110042] Make a few style tweaks to StringHasher.h : [Attachment 188744] Patch

[bugzilla-daemon at webkit.org]

Alexey Proskuryakov <ap at webkit.org> has granted Darin Adler <darin at apple.com>'s
request for review:
Bug 110042: Make a few style tweaks to StringHasher.h
https://bugs.webkit.org/show_bug.cgi?id=110042

Attachment 188744: Patch
https://bugs.webkit.org/attachment.cgi?id=188744&action=review

------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=188744&action=review


> Source/WTF/wtf/StringHasher.h:210
> +	   // FIXME: Why does this function use the version of the hash that
drops the top 8 bits?

I don't really know the answer, but it's probably somewhere between these two
comments in this file:

    // Reserving space from the high bits for flags preserves most of the
hash's 
    // value, since hash lookup typically masks out the high bits anyway. 

and

// NOTE: This class must stay in sync with the create_hash_table script in
// JavaScriptCore and the CodeGeneratorJS.pm script in WebCore.

I also suspect that these reasons don't apply to callers of hashMemory, and
this behavior is a result of a series of careless past refactorings.