On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote:
(2013/02/01 1:48), Joshua Cranmer wrote:
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote:
Sorry, it may not have been ldap code (my memory is now hazy).
But please take a look at this code. I am using comm-central code
for development/debugging TB.
https://mxr.mozilla.org/comm-central/source/mozilla/security/nss/lib/base/hash.c#53
This is NSS code, which is a separate codebase included in
mozilla-central and updated periodically.
Judging from the context, this is someone using the low 32 bits as a
hash key; since it's a hashtable, I'm going to
assume that it's expected to have some amount of collisions, so the
conversion of a possibly-64-bit pointer to a 32-bit
value is "safe" here.
Yes, I was also expecting to see the collision resolution.
But, if my reading was correct, in one place, I thought the
equality of the hash value was deemed instantly to be the equality of
the object.
(That is why I thought something was fishy, and I assume that the coder
thought it would work only under in 32bit address space. Thus the
check for 32bit
address space.)
I should have raised the flag then and there. But I went on other
things, and
later when I learned the availability of 64bit version of TB, I was
surprised.
It could be that my reading of "equality check" may have been incorrect.
Anyway, I assume that the code would bomb out by PR_ASSERT() if
incorrect usage
of this funciton in 64 bit address space is encountered at run time, and
assuming that it has not happened to anybody (?), then probably
this part of the code base is not used in production TB.
That assert says that sizeof(PLHashNumber) == sizeof(PRUint32). Which is
always true thanks to
<https://mxr.mozilla.org/comm-central/source/mozilla/nsprpub/lib/ds/plhash.h#18>.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
