Jeff King <p...@peff.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
