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 <j...@jagunet.com> 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. >
