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). -Peff