Jeff King <peff@xxxxxxxx> writes: > On Sun, May 31, 2015 at 11:16:45AM -0700, Jim Hill wrote: > >> Make strbuf_read not try to do read_in_full's job too. If xread returns >> less than was requested it can be either eof or an interrupted read. If >> read_in_full returns less than was requested, it's eof. Use read_in_full >> to detect eof and not iterate when eof has been seen. > > I think this makes sense. I somehow had to read this over several times > to understand that the main point is not the cleanup, but rather the > space savings from not doing an extra strbuf_grow. Perhaps it is because > the main idea is mentioned only in the subject. Or perhaps I was just > being dense. Even after seeing (not "reading", as it was before my first cup of caffeine ;-) this message 30 minutes ago and then reading the patch with a fresh eye, I had the same impression, until I realized there is "too" at the end of the first sentence. Perhaps The loop in strbuf_read() uses xread() repeatedly while extending the strbuf until the call returns zero. If the buffer is sufficiently large to begin with, this results in xread() returning the remainder of the file to the end (returning non-zero), the loop extending the strbuf, and then making another call to xread() to have it return zero. By using read_in_full(), we can tell when the read reached the end of file: when it returns less than was requested, it's eof. This way we can avoid an extra iteration that allocates an extra 8kB that is never used. In any case, the change is very sensible. Thanks, both. -- 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