On 21.11.2015 16:39, Yann Ylavic 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)?
+1 to apr_casecmpstr[n]() with a big fat warning in the docstring that it works for ASCII only. -- Brane