Re: [PATCH 07/17] commit: increase commit message buffer size

Derrick Stolee [off-list ref] writes:

On 7/8/2018 7:36 PM, brian m. carlson wrote:

quoted

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 <redacted>
---
  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.