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 na...@fortressintelligence.com.sg www.fortressintelligence.com.sg -----Original Message----- From: Yann Ylavic [mailto:ylavic....@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 <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.
