if the current EBCDIC validates the >< lex, then by all means update the docs to reflect that. You specifically said that "The implementation does provide ASCII numeric-alpha ordering."
The main reason I was suggesting this was that, really, it would make sense for the function to return true if they compare and 0 if not, which is, of course, not how strncasecmp does it (which is why we have the weird looking !strcasecmp() for code paths where they DO compare :) ). So by allowing that casecmpstr was not, in fact, a *replacement* implementation of strcasecmp(), we could define it to be more sensible ;) Like you said, we aren't creating a replacement clib, so creating funcs for our own specific usecase does make some sense. > On Nov 24, 2015, at 10:15 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Tue, Nov 24, 2015 at 6:35 AM, Jim Jagielski <j...@jagunet.com> wrote: > Yeah, but not, afaict, EBCDIC. > > It would help for you to review the sources. It wasn't a correct alpha sort > until I put in the EBCDIC code table this weekend, now EBCDIC chars > collate in ASCII order under this function. > > And in our use case, we > don't care (and never use) the greater/less-than functionality, > > s/our/my/;s/we/I/; - projecting much? Designing utility functions is about > designing for utility, not one case. If it is one case don't abstract it. > That's > why util[_string].c has a lot of apparently duplicate functionality that we > don't generally need under stdc '89 and APR, but we just hadn't gone back > and mopped up yet. > > just the equal to. This allows for possible other improvements/ > enhancements which might "break" the >< but doesn't affect > how *we* use it. > > Why would we break this? > > Right now you can presume that if you are looking strictly for some > encoding tokens 'chunked' 'deflate' 'gzip', you can actually walk the > token list in alpha order and find out what was missing or unexpected > in a slightly more efficient way. > >
