Re: [PATCH 04/23] prefix_ref_iterator: don't trim too much

> > I suspect it's undefined behavior according to the standard, though I'd
> > guess in practice it would be fine. But if I'm understanding it
> > correctly, this is the same check as:
> > 
> >   if (strlen(iter->iter0->refname) <= iter->trim)
> > 
> > which seems a lot more obvious to me and doesn't fall afoul of weird
> > standard issues. The only downside I see is that it would read to the
> > end of string when yours could stop at iter->trim bytes. I have no idea
> > if that would be measurable (it might even be faster because strlen()
> > only has one condition to loop on).
> 
> You are correct that I chose `memchr()` over `strlen()` to avoid
> scanning a POTENTIALLY EXTREMELY LARGE NUMBER OF CHARACTERS past the
> trim length, but of course in real life refnames aren't that long and
> `strlen()` might actually be faster.

> I *think* `memchr()` is technically OK:
> 
> > Implementations shall behave as if they read the memory byte by byte
> from the beginning of the bytes pointed to by s and stop at the first
> occurrence of c (if it is found in the initial n bytes).