зеркало из https://github.com/microsoft/git.git
rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
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>
This commit is contained in:
Родитель
bac9c06ba0
Коммит
5743350f69
10
rerere.c
10
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;
|
||||
|
|
Загрузка…
Ссылка в новой задаче