> On Nov 21, 2015, at 10:39 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
>
> On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej <br...@apache.org> wrote:
>> On 21.11.2015 09:31, Graham Leggett wrote:
>>> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr <wr...@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)?
>
Yeah... I like the name apr_casecmpstr[n]()
