On 3/7/13, Junio C Hamano <gits...@pobox.com> wrote:
> The parser that goes past the end of the string may be a bug worth
> fixing, but is this patch sufficient to diagnose such an input as an
> error?

Yea, the patch should fix the passing end of string too. The parser
was going past end of string because the nextat is set to "copyfrom +
len + 1" for the '\0' case too. Then "+ 1" causes the parser to go
pass end of string. If we handle the '\0' case separately, then the
parser ends properly, and shouldn't be able to go pass the end of

Hm, should I be paranoid and put an "else" clause to call die() as
well? In case there's a scenario where none of the 3 cases is true...

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to