apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: Provide our own impl of str[n]casecmp()?
Date Mon, 23 Nov 2015 08:11:32 GMT
On 21.11.2015 16:39, Yann Ylavic wrote:
> On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej <brane@apache.org> wrote:
>> On 21.11.2015 09:31, Graham Leggett wrote:
>>> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>>>> Any objections to picking this up for APR 1.next/2.0?
>>>> It seems that httpd isn't the only one who wants to be strict about
>>>> case-insensitive token string recognition, and non-POSIX char case
>>>> gets weird quickly.
>>> +1 to this.
>>> Ideally we should add it to APR, and then provide a convenience function in httpd
that has the same implementation when the function in APR is missing, and use the APR function
when present.
>> Does it matter that this implementation assumes that the runtime
>> encoding is a superset of ASCII? (FWIW, it doesn't even handle the
>> Unicode Latin-1 range).
> It doesn't matter IMHO, strcasecmp() is defined in the POSIX ("C")
> locale only, and this implementation is equivalent to any strcasecmp()
> in that locale (though strcasecmp() run in another locale could
> produce different results for chars >127).
> The goal would be an efficient implementation on all platforms, for
> ASCII text only (e.g. tokens), where '\xC9' ('É') would be different
> than '\xE9' ('é') but meh :p
> Maybe we could choose another name to avoid any confusion,
> apr_tokencmp() or apr_casecmpstr[n]() (à la cpystrn)?

+1 to apr_casecmpstr[n]() with a big fat warning in the docstring that
it works for ASCII only.

-- Brane

View raw message