My point is that we use it to compare, for example, "FoobARski!" with "foOBArsKi!", not "Ébana?" with "ébana?" or "ebana?"
In that way I mean "ascii" Heck, we may as well say that we really aren't comparing "strings" at all, just arrays of 8bit characters :) Anyway, that was my final post about the name... at this point I'd just like to see the actual improvement get completely folded in and used so we (and our users) can start enjoying the benefit. > On Nov 25, 2015, at 2:31 PM, William A Rowe Jr <[email protected]> wrote: > > On Wed, Nov 25, 2015 at 1:12 PM, Jim Jagielski <[email protected]> wrote: > > > On Nov 25, 2015, at 12:42 PM, William A Rowe Jr <[email protected]> wrote: > > > > On Wed, Nov 25, 2015 at 10:17 AM, Jim Jagielski <[email protected]> wrote: > > What is the current status? Is this on hold? > > > > It is looking for a good name. I'm happy with apr_token_strcasecmp > > to best indicate its use-case and provenance. Does that work for > > everyone? > > Still not super excited by the use of 'token' since it > implies it should only be used for HTTP tokens and not > in other cases where we use it to do ascii string comparisons > (for example, when we check env-var settings or maybe directives)... > yeah, they could also be lumped as 'tokens' I guess... > > ap_casecmpastr[n] for Case-insensitive CoMParison of Ascii STRing > > APR has a naming pattern for various functional groups - this won't be the > last > one that is impacted by POSIX-ing what should already be posix :) > > Because this is (a) str[n]casecmp I'm pretty strongly against name mangling > for the sake of name mangling, our consumers are C programmers, after all. > Well, most of them anyways... and they should be familiar enough names > for the Lua and PHP folks too. > > And this isn't ASCII actually, we established that we want EBCDIC build of > APR + HTTPD to have the same thing. Not ASCII, but POSIX locale. We > will be careful about the description on that count. > > Still -0.5 on introducing an ap_function, in light of the current mess in > httpd.h. > I'm only 10% of the way through reviewing @deprecated on that single header. > >
