On Tue, Nov 24, 2015 at 9:28 AM, Jim Jagielski <j...@jagunet.com> 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 :)
