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. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html