We have both: static PRInt32 strncmp(const char* s1, const char* s2, PRUint32 aMaxLen) and static PRInt32 strncmp(const char* s1, const char* s2, PRInt32 aMaxLen) The latter does some wierd 'optimisation' to compare the first character. Other than that, they are identical, except that the 'optimisation' doesn't handle aMaxLen==0. I broke the mac yesterday when one of my calls called this with a paramater of sizeof(foo)-1, when it complained that the call was ambiguous. I have no idea whether it was right or not, but its silly to have two versions of this. Can we get rid of the signed one?
not sure what the rationale was. The same was done to the strncmp that takes PRUnichars.
for |const char*| let's use the native strncmp. for |const PRUnichar*| we should also use the native version (e.g. wcsncmp) when provided natively (win32, linux, etc).
We can only use native functions on platforms where the native functions accept two byte encodings. (ie not linux)
so i'm on my redhat 7.2 box, and i look in /usr/include and i see a file called wchar.h. i open it and i find wcsncmp and friends. now i suppose this is probably a new addition or something, but shouldn't we check for it (via autoconf) and use it when available?
No, you can't use those. Those routines are compiled into libc, which uses a 4 byte wchar_T, which is the linux abi. We use two byte wchar_t, and so all the libc functions wouldn't read the string correctly. On windows, which does have a 2 byte wchar_t abi, you probably could use those. There are still encoding issues, possibly, though.
ah interesting... ok, well we should try to at least use the win32 ones if they prove to be compatible.
cathleen is this something that you are cleaning up?
The double strncmp issue is fixed with Bug 124536, attachment: https://bugzilla.mozilla.org/attachment.cgi?id=135660 Which is not yet checked in. The wchar discussion is not for this bug. So dupping this bug 124536. *** This bug has been marked as a duplicate of 124536 ***