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)?
Regards,
Yann.
