git patch-id fails on long lines

In patch-id.c, get_one_patchid uses a fixed 1000-char buffer to read a line.[1] This causes incorrect results on longer lines. Pasted below is a git commit (from git show) that demonstrates the problem. The result of running git patch-id on this commit is:

9220f380851be9cab1a760430e3be096dcbee8c6 9b96b6fde8f7df791a1490ae18e1fa75fbab3262 74b8ede07628a574fd586624e0c77a4b6c9967e0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

The commit:

commit 9b96b6fde8f7df791a1490ae18e1fa75fbab3262

Author: Andrew Pimlott <[email protected]>
Date:   Tue Sep 20 10:53:25 2011 -0700

    2

index e69de29..2e6adac 100644
@@ -0,0 +1 @@
+aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

index e69de29..1425fcc 100644
@@ -0,0 +1 @@
+b

Andrew

[1] https://github.com/git/git/blob/master/builtin/patch-id.c

Hmm, yeah. My initial impression "eh, so what, it will just add the line contents to the sha1 patch-id in two separate hunks". But we actually treat lines magically based on their beginnings, and it seems we accidentally think the "aaa" is the start of the next commit header.

I think this can be trivially converted to use strbuf_getwholeline, something like this (completely untested):

index f821eb3..99ba2ca 100644
@@ -58,11 +58,12 @@ static int scan_hunk_header(const char *p, int *p_before, int *p_after)
 
 static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx)
 {
-	static char line[1000];
+	static struct strbuf line_buf = STRBUF_INIT;
 	int patchlen = 0, found_next = 0;
 	int before = -1, after = -1;
 
-	while (fgets(line, sizeof(line), stdin) != NULL) {
+	while (strbuf_getwholeline(&line_buf, stdin, '\n') != EOF) {
+		char *line = line_buf.buf;
 		char *p = line;
 		int len;
 

That just reuses the same heap-allocated buffer over and over, and then eventually leaks it at the end (but then the program exits anyway). You could get fancier and actually pass in the strbuf from generate_id_list, and then release it when we're done.

-Peff

Thanks; builtin/patch-id.c is parhaps one of the more ancient part of the system and it hasn't been updated to use more modern facility like strbuf API.

Fix should be pretty straightforward. Any takers?

get_one_patchid() uses a rather dumb heuristic to determine if the passed buffer is part of the next commit. Whenever the first 40 bytes are a valid hexadecimal sha1 representation, get_one_patchid() returns next_sha1.
Once the current line is longer than the fixed buffer, this will break (provided the additional bytes make a valid hexadecimal sha1). As a result patch-id returns incorrect results. Instead, user strbuf and read one line at a time.

---
 builtin/patch-id.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

index f821eb3..3cfe02d 100644
@@ -56,13 +56,13 @@ static int scan_hunk_header(const char *p, int *p_before, int *p_after)
 	return 1;
 }
 
-static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx)
+static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx, struct strbuf *line_buf)
 {
-	static char line[1000];
 	int patchlen = 0, found_next = 0;
 	int before = -1, after = -1;
 
-	while (fgets(line, sizeof(line), stdin) != NULL) {
+	while (strbuf_getwholeline(line_buf, stdin, '\n') != EOF) {
+		char *line = line_buf->buf;
 		char *p = line;
 		int len;
 

@@ -133,14 +133,16 @@ static void generate_id_list(void)
 	unsigned char sha1[20], n[20];
 	git_SHA_CTX ctx;
 	int patchlen;
+	struct strbuf line_buf = STRBUF_INIT;
 
 	git_SHA1_Init(&ctx);
 	hashclr(sha1);
 	while (!feof(stdin)) {
-		patchlen = get_one_patchid(n, &ctx);
+		patchlen = get_one_patchid(n, &ctx, &line_buf);
 		flush_current_id(patchlen, sha1, &ctx);
 		hashcpy(sha1, n);
 	}
+	strbuf_release(&line_buf);
 }
 
 static const char patch_id_usage[] = "git patch-id < patch";

1.7.7.rc2.365.g55c1f

A minor nit, but I think this is probably broken even if the additional bytes don't look like a valid sha1. It would look like cruft after the diff (since the lien doesn't start with plus, minus, or space), which means it would not be stirred into the sha1 mix.

The patch itself looks good to me, though. Thanks.

-Peff