get rid of the helper classes in nsAbUtils.h we should we able to use the datastructures (like nsCStringArray and nsStringArray, etc) that are already in mozilla. no reason for more bloat.

taking

If you look more closely, these datastructures are required to convert from char** to nsCStringArray and from PRUnichar** to nsStringArray. we cannot remove them. nsCStringArrray and nsStringArray are not native types and therefore cannot be used in idl files, which needs these conversion (both ways).

if I've got a bunch of char*, can't I do this: nsCString foo; foo.Adopt(ptr); nsCStringArray.Append(foo); or something. we can have interfaces that use nsCStringArray and nsStringArray, they just won't be scriptable. do we really need to pass these through JS?

those helper classes are just in C++, so it doesn't even matter. I think we can get rid of that code, if we just use Adopt() properly.

talking with dmose and naving, if we decide to clean this up, we'll need keep it scriptable. so my original suggestion will not work. searchExt() is part of a scritable interface nsILDAPOperation.idl. where do we call it from js? and that's called from the ldap datasource, see nsLDAPDataSource.js so if we want to go down this road, we'd either use nsISupportsArray and nsISupportsString and nsISupportsWString, or move these impls to mozilla/xpcom/ds, as they are useful. one draw back of changing is we'd have to change from XPCOM-style arrays (around the char **) to nsISupportsArrays. we'd have to fix at least the LDAP addrsesbook code, the LDAP autocomplete code, the LDAP URL handling code, and datasource. re-assigning to dmose. this undertaking is right up his alley, and may involve a lot of LDAP ab-LDAP work. futuring.

I've gotten rid of some of the helper classes. see bug #83091

the hash table bloat is gone, 83091 has landed.

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.