Derrick Stolee <sto...@gmail.com> writes:
> On 7/8/2018 7:36 PM, brian m. carlson wrote:
>> 100 bytes is not sufficient to ensure we can write a commit message
>> buffer when using a 32-byte hash algorithm. Increase the buffer size to
>> ensure we have sufficient space.
>>
>> Signed-off-by: brian m. carlson <sand...@crustytoothpaste.net>
>> ---
>> refs/files-backend.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/refs/files-backend.c b/refs/files-backend.c
>> index a9a066dcfb..252f835bae 100644
>> --- a/refs/files-backend.c
>> +++ b/refs/files-backend.c
>> @@ -1587,7 +1587,7 @@ static int log_ref_write_fd(int fd, const struct
>> object_id *old_oid,
>> char *logrec;
>> msglen = msg ? strlen(msg) : 0;
>> - maxlen = strlen(committer) + msglen + 100;
>> + maxlen = strlen(committer) + msglen + 200;
>> logrec = xmalloc(maxlen);
>> len = xsnprintf(logrec, maxlen, "%s %s %s\n",
>> oid_to_hex(old_oid),
>
> nit: 100 is not enough anymore, but wasn't a very descriptive
> value. 200 may be enough now, but I'm not sure why.
As Brandon alludes to downthread, we probably should use strbuf for
things like this these days, so a preliminary clean-up to do so is
probably a welcome change to sneak in and rebase this series on top
of.
"%s %s %s\n" with old and new commit object name and the message
will be "2 * len(hash_in_hex) + 4" bytes long (counting the three
whitespaces and the terminating NUL), and Shawn's original in
6de08ae6 ("Log ref updates to logs/refs/<ref>", 2006-05-17) actually
computed this one as "strlen(...) + 2*40+4".
100 was merely me being sloppier than Shawn at 8ac65937 ("Make sure
we do not write bogus reflog entries.", 2007-01-26), preferring
being sufficient over not wasting even a single byte.
