apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: Provide our own impl of str[n]casecmp()?
Date Mon, 23 Nov 2015 07:30:11 GMT
Hello Nadia,

you are probably subsribed to the dev@apr.apache.org mailing list (no BCC here).
To unsubscribe, just send an email to dev-unsubscribe@apr.apache.org.

Regards,
Yann.

On Mon, Nov 23, 2015 at 2:45 AM, Nadia
<nadia@fortressintelligence.com.sg> wrote:
> Hello Yann,
>
> I've been in this email thread for the longest time and am not involved in any of this.
Please remove my email from the bcc thread please. Thanks.
>
> Yours sincerely,
> Nadia Majeed (R1442647)
> Project Specialist
> Fortress Intelligence Pte Ltd (EA No: 10C4262)
> 10 Anson Road
> #34-11 International Plaza
> Singapore 079903
> Tel: (65) 6334 8311
> Fax: (65) 6334 8511
> nadia@fortressintelligence.com.sg
> www.fortressintelligence.com.sg
>
> -----Original Message-----
> From: Yann Ylavic [mailto:ylavic.dev@gmail.com]
> Sent: Saturday, 21 November, 2015 11:39 PM
> To: apr-dev <dev@apr.apache.org>
> Subject: Re: Provide our own impl of str[n]casecmp()?
>
> 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)?
>
>
> Regards,
> Yann.
>
>
>

Mime
View raw message