You are right. I figured out the issue. It would be nice to ASSERT in the hash() functions (instead of in the header) so people who encounter the NULL input will understand immediately something else is wrong.
On Wed, Apr 13, 2011 at 6:04 PM, Gavin Barraclough <[email protected]> wrote: > On Apr 13, 2011, at 5:32 PM, Mo, Zhenyao wrote: > > What value should we return for hash(NULL)? > > From the top of the file: > // The hash() functions on StringHash and CaseFoldingHash do not support > // null strings. get(), contains(), and add() on HashMap<String,..., > StringHash> > // cause a null-pointer dereference when passed null strings. > In the hash traits for String, we use String() as the empty value for hash > tables keyed on a string. Our hash tables will not work correctly if the > hash trait's empty value is used as a key in the table, so allowing a null > string to be hashed & used as a key would only result in later errors. We > should probably ASSERT in the hash methods that the Strings/StringImpls > passed to the hash() methods in StringHash are not null. > To fix your problem you will need to find what is using a null string as a > key in a hashtable, and stop it – making hash() return a value for the null > string will not fix this bug. > cheers, > G. > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
