Pay special attention to; The *strncasecmp*() function shall compare, *while ignoring differences in case*, not more than *n* bytes from the string pointed to by *s1* to the string pointed to by *s2*.
In the POSIX locale, *strcasecmp*() and *strncasecmp*() shall *behave as if the strings had been converted to lowercase* and then a byte comparison performed. The results are unspecified in other locales. http://pubs.opengroup.org/onlinepubs/009695399/functions/strcasecmp.html E.g. 0x5B-0x60 sort before alpha. If you don't want to honor posix semantics, don't abuse the "strcmp" concept, but rather name this "streq" or something otherwise less confusing :-) On Fri, Nov 20, 2015 at 12:22 PM, William A Rowe Jr <[email protected]> wrote: > I'm +1 if you are suggesting an ascii-only implementation, and by all means > introduce both an ap_ and apr_ flavor at the same time. > > E.g. apr[r]_ascii_str[n]casecmp(). > > All characters <'A' || >'Z' && <'a || >'z' should be compared by identity. > > I'm not sure which OS/X implementation you are referring to, though... > > http://www.opensource.apple.com/source/Libc/Libc-1044.40.1/string/FreeBSD/strcasecmp.c > > That implementation reminds us that we shouldn't be trusting these local > code page implementations for comparing defined ascii tokens, and many > of our comparisons in httpd are for such purposes. > > But since a non-locale based ascii implementation comparing > tolower(x)-tolower(y) devolves to chrtable[x]-chrtable[y], where > tolower is inline, and if we intend to preserve the defined <0 == >0 > behavior of the K&R definition, you do need to fold. > > Yes the switch/case is ugly, but far more efficient for a larger set of > values/tokens. One optimization would be iterating the pre-sorted > list of tokens in a binary fashion with a near skip pointer or returning > the elt of that item, but that would quickly become as crufty, subject > to bugs and unmaintainable as the usual switch/case solution. > > > > On Fri, Nov 20, 2015 at 11:17 AM, Jim Jagielski <[email protected]> wrote: > >> We use str[n]casecmp quite a bit. The rub is that some >> platforms use a sensible implementation (such as OSX) which >> uses a upper-lowercase map and is v. fast, and others >> use a brain-dead version which does an actual tolower() of >> each char in the string as it tests. We actually try to >> handle this in many cases by doing a switch/case test on the >> 1st char to fast path the strncasecmp, resulting in ugly code. >> >> This is crazy. >> >> I propose a ap_strncasecmp/ap_strcasecmp which we should use. >> Ideally, it would be in apr but no need to wait for that >> to happen :) >> >> Unless people have heartburn about this, I will add next week. >> > >
