On Wed, Nov 25, 2015 at 1:50 PM, Jim Jagielski <j...@jagunet.com> wrote:
> 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" > But that isn't precisely what you wrote. It happens to be ASCII here because we are corresponding in some offshoot of ISO646 (and yours might be different than mine, but gmail resolved it). We have an EBCDIC modality for APR and for httpd, and in that case, it is exactly what you meant (only A-Z, a-z) but not what you wrote :) > Heck, we may as well say that we really aren't comparing > "strings" at all, just arrays of 8bit characters :) > True, almost. That's why I reiterated that the 8-bit values are largely opaque to the "C" locale. As long as A-Z, a-z behave as 'we' expect with protocol conformance, we aren't so worried about the rest, and that applies equally in ASCII or EBCDIC or Baudôt. 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. > In terms of your perceived optimization, I'd hate to have the result that OS/X hobbled users gain a faster strcmp implementation while others realize a slower implementation, and I'm thinking of non-locale aware BSD. That's often the case with "optimizations" that don't consider what the clib maintainers are able to accomplish with specialized knowledge of the target architecture (especially MMX operations across arrays of characters). And we long ago decided that APR really isn't cut out for those sorts of optimizations. I'm also waiting for feedback about the naming convention, I'd like to get this into APR yesterday and start building on it, but it's hard to name our generic-posix tolower/toupper until we agree on the naming scheme :)
