Calls to nsCString::CompareWithConversion with a const nsCString& end up calling the version that takes const char* and thus have to call strlen in order to init a new nsCString and do the compare. I saw this in parser code that uses nsAVLTree. I actually intend to fix that code to not use nsAVLTree or nsCString::CompareWithConversion, but this might be a problem elsewhere.

Well... CompareWithConversion wouldn't make much sense if no conversion is required. It looks like nsCString::Compare should do the trick but doesn't. And, nsStr::StrCompare is whacky because it requires a count (if I want to specify the ignoreCase flag), but figuring out how the counts in the two strings compare is part of the reason this code would be calling the stupid function - I don't want to have to pass it in and it would matter which string I got the count from! *Assuming* that one wants to do case-insensitive compares of nsCStrings, then I think this api is broken. For the code I'm looking at I'm just going to remove the reason for doing case-insensitve compares. I don't really need anything fixed, but the api is screwy. And *somebody* used it wrong in a few places in the parser.

changing the summary to "fix string comparison APIs" which I want to have done for 0.9.

So what this bug really is, is ``need case-insensitive comparisons for new strings''; which is also the point of bug #70740. Marking this one a duplicate. *** This bug has been marked as a duplicate of 70740 ***