Bug 110042 - Make a few style tweaks to StringHasher.h
Summary: Make a few style tweaks to StringHasher.h
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-16 16:52 PST by Darin Adler
Modified: 2013-02-18 17:46 PST (History)
4 users (show)

See Also:

Attachments
Patch (6.36 KB, patch)
2013-02-16 17:11 PST, Darin Adler 		ap: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2013-02-16 16:52:11 PST 
Reduce use of abbreviations in StringHasher.h
Comment 1 Darin Adler 2013-02-16 17:11:26 PST 
Created attachment 188744 [details]
Patch
Comment 2 Alexey Proskuryakov 2013-02-17 13:07:54 PST 
Comment on attachment 188744 [details]
Patch

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.
Comment 3 Darin Adler 2013-02-18 17:46:42 PST 
Committed r143280: <http://trac.webkit.org/changeset/143280>