Re: [PATCH 04/23] prefix_ref_iterator: don't trim too much
- Date: Wed, 17 May 2017 10:22:06 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH 04/23] prefix_ref_iterator: don't trim too much
On Wed, May 17, 2017 at 04:11:15PM +0200, Michael Haggerty wrote:
> > 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.
Heh. Yeah, I actually did dig up a glibc thread that says that strlen()
is even faster than rawmemchr(). But they were discussing buffer sizes
of at least 1K. For refnames I doubt it matters much at all.
> 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).
Interesting. I don't really see how else you'd implement it, so that
makes sense (your quote is from POSIX; I first looked in C99, but
couldn't find any similar language there).