Re: [PATCH 3/6] revert: fix buffer overflow in insn sheet parser

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2011, 17:15 UTC
Message-ID: <7vmxcva8k1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111020090912.GA21471@elie.hsd1.il.comcast.net>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 17 quoted lines

> Looks good, except I would explain it differently, to avoid referring
> to hypothetical implementation details ("What buffer overflow?"):
>
> 	test: git cherry-pick --continue should cope with long object names
>
> 	A naive implementation that uses a commit-id-shaped buffer
> 	to store the word after "pick" in .git/sequencer/todo lines
> 	would crash often.  Our implementation is not so naive, but
> 	add a test anyway to futureproof it.
>
> Or:
>
> 	test: make sure the "cherry-pick --continue" buffer overflow doesn't come back
>
> 	Before commit ..., "git cherry-pick --continue" would overflow
> 	under ... circumstance.  Add a test to make sure it doesn't
> 	happen again.

I doubt you would need any of that.

You can just explain the commit that stops copying the lines into a private, fixed buffer a bit better (e.g. "such copying is not just wasteful but is wrong by unnecessary placing an artificial limit on the line length"), and say "Incidentally, this fixes a bug in the earlier round of this series that failed to read lines that are too long to fit on the buffer, demonstrated by the test added by this patch", or something.

Then the additional test can become part of the patch that corrects the parsing logic, no?