Closed
Bug 254252
Opened 20 years ago
Closed 20 years ago
nsCRT::BufferHashCode has two variants, and only one user, HashCodeAsUTF8 has no users
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: mikael, Assigned: mikael)
References
()
Details
(Keywords: memory-footprint)
Attachments
(1 obsolete file)
nsCRT::BufferHashCode has two variants, and only one consumer, one could be removed. The consumer (http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsHTMLValue.h#140 ) uses the char*-version but maybe it should use the PRUnichar*-version? Anyway, one of these variants could be removed.
Assignee | ||
Comment 1•20 years ago
|
||
It also looks like HashCodeAsUTF8 has no consumer at all. http://lxr.mozilla.org/seamonkey/search?string=HashCodeAsUTF8
Assignee | ||
Comment 2•20 years ago
|
||
replace consumer with user in previous comments
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: nsCRT::BufferHashCode has two variants, and only one consumer → nsCRT::BufferHashCode has two variants, and only one user, HashCodeAsUTF8 has no users
Assignee | ||
Updated•20 years ago
|
Assignee: dougt → mikael
Status: ASSIGNED → NEW
Assignee | ||
Comment 3•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #155374 -
Flags: superreview?(bzbarsky)
Attachment #155374 -
Flags: review?(darin)
Comment 4•20 years ago
|
||
Comment on attachment 155374 [details] [diff] [review] patch Looks fine to me if darin's OK with it. sr=bzbarsky.
Attachment #155374 -
Flags: superreview?(bzbarsky) → superreview+
Comment 5•20 years ago
|
||
Comment on attachment 155374 [details] [diff] [review] patch Hmm... changing to the wide version of BufferHashCode appears to change the hashing algorithm since it will be combining 16-bit units instead of 8-bit units, or am I mistaken? I can't see any reason why that should matter, unless some other code elsewhere is using PL_HashString or some other implementation of the same algorithm as the narrow version of BufferHashCode. Are we 100% sure this isn't going to cause wierd side-effects? I find it odd that jkeiser added the wide version of BufferHashCode at the same time that he added this HashCode function. Do you think he just mistakenly used the narrow version to begin with? (It did go through 3 reviewers... chalk it up to a typo or could there be some real reason behind his choice?) Also, seems like a shame to throw away such good code for computing the UTF-8 equivalent hash on a UTF-16 string. Maybe we should just "#if 0" the code in case someone needs it again? r=darin
Attachment #155374 -
Flags: review?(darin) → review+
Comment on attachment 155374 [details] [diff] [review] patch mozilla/content/base/src/nsHTMLValue.h 3.42 mozilla/xpcom/ds/nsCRT.cpp 3.56 mozilla/xpcom/ds/nsCRT.h 3.72
Attachment #155374 -
Attachment is obsolete: true
Comment 8•20 years ago
|
||
Argh! I'm using HashCodeAsUTF8(). timeless, it'd been nice if you'd followed darin's sr commeints before checking this in...
Assignee | ||
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•