On Mon, Nov 11, 2013 at 05:09:17PM +0100, Andreas Ericsson wrote:
> On 2013-11-09 08:05, Christian Couder wrote:
> >Here is a big patch series to replace prefixcmp() with a new
> >has_prefix() function.
> Seems like totally useless codechurn to me. Besides, prefixcmp()
> ties in nicely with strcmp() and memcmp() (and returns 0 on a
> match just like its namesakes), whereas your function must return
> non-zero on match and thus can't be used as a qsort() callback.
> Granted, prefixcmp() lends itself poorly to that as well, but at
> least it's consistent with the other *cmp() functions.
I think you missed the earlier threads that let up to this, but the
summary is that prefixcmp does not really make any sense as a qsort
callback. Consider that comparing "foobar" and "foo" would yield 0, but
"foo" and "foobar" would be positive.
I am ambivalent on the code churn, but if we do apply it, we should
probably leave off the final patch (dropping prefixcmp) for a cycle to
let topics in flight catch up to the change. Just diffing "master" and
"next", I see some new uses of prefixcmp which will need adjusted, along
with spots where the patches themselves will cause textual conflicts.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html