On Wed, Sep 20, 2017 at 01:25:43PM -0700, Stefan Beller wrote:
> > +/* Return -1, 0, 1 if refname is before, inside, or after the prefix. */
> > +static int compare_prefix(const char *refname, const char *prefix)
> > +{
> > + while (*prefix) {
> > + if (*refname != *prefix)
> > + return ((unsigned char)*refname < (unsigned
> > char)*prefix) ? -1 : +1;
>
> This looks interesting.
>
> We get a signed char* , cast it to unsigned char* and then
> compare byte by byte.
>
> The cast lead me to think that this should work for non-ASCII
> (e.g. ANSI?), but given that there are multi-byte characters (e.g.
> UTF-8) depending on your encoding used, we may not assume
> that in the given encoding the characters order by their byte order?
We don't really care about encodings here. We're doing a byte-wise
comparison. Which may include high-bit bytes for some encodings.
The important thing is that it match the byte-wise comparison that we
use elsewhere (e.g., in memcmp or strcmp), since our sort order must be
the same. And those functions are defined to do the funny "subtract as
unsigned" rule.
> But this compare function is not to order by the natural encoding order,
> but it's used to detect the '0' at the end of prefix, which orders
> before *any* unsigned char.
It's not just detecting the "0". We care about the ordering overall (so
that "refs/foo" comes after "refs/bar", and we know that "refs/bar/baz"
cannot come after "refs/foo", and we can stop iterating).
> We cannot enhance starts_with for this case as we'd have to invert
> the return value to differentiate between the prefix ordering before
> or after the given string.
Exactly. starts_with() is about a boolean match. But this is inherently
about matching the ordering of other "cmp" functions, but for a partial
match. It's possible that's something we could use in a more general
case, but I don't know of one offhand.
> Essentially compare_prefix wants to provide the same return
> value as `strncmp(refname, prefix, min(strlen(refname), strlen(prefix)));`
> except that it is optimized as we do not have to walk over a string
> multiple times (to determine length and then pass it to compare).
Hmm, yeah, I think that would be an equivalent. I didn't think of that,
but as you say it would be less efficient.
> Feel free to ignore the rambling, I just had to sort my thoughts.
> The patch looks good.
Rambling is sometimes good if it points out holes in the original
reasoning.
The patch is credited to me, but I actually screwed up the ordering by
failing to do the unsigned cast. Michael fixed that part before posting
it. :)
-Peff
