Code

rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
authorJim Meyering <jim@meyering.net>
Thu, 26 May 2011 13:54:18 +0000 (15:54 +0200)
committerJunio C Hamano <gitster@pobox.com>
Thu, 26 May 2011 18:07:52 +0000 (11:07 -0700)
If we reach EOF after the SHA1-then-TAB, yet before the NUL that
terminates each file name, we would fill the file name buffer with \255
bytes resulting from the repeatedly-failing fgetc (returns EOF/-1) and
ultimately complain about "filename too long", because no NUL was
encountered.

Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere.c

index d2608434750c336c3f3881efda8373b7c67d4b11..283a0024b05706b98e8056ac20258bf9248b80c7 100644 (file)
--- a/rerere.c
+++ b/rerere.c
@@ -42,8 +42,14 @@ static void read_rr(struct string_list *rr)
                name = xstrdup(buf);
                if (fgetc(in) != '\t')
                        die("corrupt MERGE_RR");
-               for (i = 0; i < sizeof(buf) && (buf[i] = fgetc(in)); i++)
-                       ; /* do nothing */
+               for (i = 0; i < sizeof(buf); i++) {
+                       int c = fgetc(in);
+                       if (c < 0)
+                               die("corrupt MERGE_RR");
+                       buf[i] = c;
+                       if (c == 0)
+                                break;
+               }
                if (i == sizeof(buf))
                        die("filename too long");
                string_list_insert(rr, buf)->util = name;