alternates: store scratch buffer as strbuf
commit38dbe5f07837afceaec95fae5981d36eeb4917bd
authorJeff King <peff@peff.net>
Mon, 3 Oct 2016 20:36:04 +0000 (3 16:36 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 10 Oct 2016 20:52:36 +0000 (10 13:52 -0700)
treec8b54f0504b7c23df0927b393faf0fe5dc6256e1
parentafbba2f09ab06424d8b38908f4d76a1503f49a25
alternates: store scratch buffer as strbuf

We pre-size the scratch buffer to hold a loose object
filename of the form "xx/yyyy...", which leads to allocation
code that is hard to verify. We have to use some magic
numbers during the initial allocation, and then writers must
blindly assume that the buffer is big enough. Using a strbuf
makes it more clear that we cannot overflow.

Unfortunately, we do still need some magic numbers to grow
our strbuf before calling fill_sha1_path(), but the strbuf
growth is much closer to the point of use. This makes it
easier to see that it's correct, and opens the possibility
of pushing it even further down if fill_sha1_path() learns
to work on strbufs.

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