fill_sha1_file: write into a strbuf
commitf7b7774f34b86fed8a2e9554a9fe865c62a0a5eb
authorJeff King <peff@peff.net>
Mon, 3 Oct 2016 20:36:09 +0000 (3 16:36 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 10 Oct 2016 20:52:37 +0000 (10 13:52 -0700)
tree7200a36bc78de1d5bd39381081579f10db7b6cc5
parent38dbe5f07837afceaec95fae5981d36eeb4917bd
fill_sha1_file: write into a strbuf

It's currently the responsibility of the caller to give
fill_sha1_file() enough bytes to write into, leading them to
manually compute the required lengths. Instead, let's just
write into a strbuf so that it's impossible to get this
wrong.

The alt_odb caller already has a strbuf, so this makes
things strictly simpler. The other caller, sha1_file_name(),
uses a static PATH_MAX buffer and dies when it would
overflow. We can convert this to a static strbuf, which
means our allocation cost is amortized (and as a bonus, we
no longer have to worry about PATH_MAX being too short for
normal use).

This does introduce some small overhead in fill_sha1_file(),
as each strbuf_addchar() will check whether it needs to
grow. However, between the optimization in fec501d
(strbuf_addch: avoid calling strbuf_grow, 2015-04-16) and
the fact that this is not generally called in a tight loop
(after all, the next step is typically to access the file!)
this probably doesn't matter. And even if it did, the right
place to micro-optimize is inside fill_sha1_file(), by
calling a single strbuf_grow() there.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c