httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: strncasecmp
Date Fri, 20 Nov 2015 18:26:50 GMT
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.

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 <>

> 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
> I'm not sure which OS/X implementation you are referring to, though...
> 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 <> 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.

View raw message