| Summary: | Make a few style tweaks to StringHasher.h | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Adler <darin> | ||||
| Component: | Web Template Framework | Assignee: | Darin Adler <darin> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | benjamin, cmarcelo, ojan.autocc, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Darin Adler
2013-02-16 16:52:11 PST
Created attachment 188744 [details]
Patch
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. Committed r143280: <http://trac.webkit.org/changeset/143280> |