(2013/02/01 11:34), Joshua Cranmer wrote:
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>.

Hmm. I will re-read this and make sure if I understand this correctly.

TIA

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to