httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1715859 - /httpd/httpd/trunk/include/httpd.h
Date Tue, 24 Nov 2015 15:41:25 GMT
On Tue, Nov 24, 2015 at 9:28 AM, Jim Jagielski <> wrote:

> 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."

You are right, calling out "This implementation provides ASCII-ordering
of strings (EBCDIC text is also ASCII ordered on those platforms)"
might have been clearer?  Eric, what phrasing would make sense to you
as a user/maintainer of the httpd EBCDIC port?

> 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 ;)

That's possible, although I'm -.5 on losing the functionality for the
earlier reasons stated, and your interpretation is incorrect.  "cmp"
implies compare, lt, 0, gt valuations. "eq" implies equality tests.

Like you said, we aren't creating a replacement clib, so creating
> funcs for our own specific usecase does make some sense.

Sure, and the use case(s) can be broad enough to serve more than
one purpose.

If you really need a strict equality test, isn't

#define ap_strcaseequals(s1, s2) (!ap_strcasecmp(s1, s2)) sufficient?

(or choose match or identity but not cmp, please :)

View raw message