httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r1715859 - /httpd/httpd/trunk/include/httpd.h
Date Tue, 24 Nov 2015 15:28:20 GMT
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 <> wrote:
> On Tue, Nov 24, 2015 at 6:35 AM, Jim Jagielski <> 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. 

View raw message