Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
On 03/07/13 20:51, Junio C Hamano wrote: > But it is equally broken to behave as if there is nothing wrong in > the incomplete magic ":(top" that is not closed, isn't it? Ah, yea, I did notice that, but then I saw a few lines below: if (*copyfrom == ')') copyfrom++; which is explicitly making the ")" optional. So I thought maybe that was the original intention, and left it at that. Though the doc says to end with ")", so I guess it should error out after all? If that's the case, I can try to come up with a patch to error it out (through die() ?). -- 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
Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
Andrew Wong writes: > On 3/7/13, Junio C Hamano wrote: >> This did not error out for me, though. >> >> $ cd t && git ls-files ":(top" > > No error message at all? Hm, maybe in your case, the byte after the > end of string happens to be '\0' and the loop ended by chance? > > git doesn't crash for me, but it generates this error: > $ git ls-files ":(top" > fatal: Invalid pathspec magic 'LS_COLORS=' in ':(top' What I meant was that I do not get any error _after_ applying your patch. It is broken to behave as if "LS_COLORS=..." (which is totally unrelated string that happens to be laid out next in the memory) is a part of the pathspec magic specification your ":(top" started. Your patch makes the code stop doing that. But it is equally broken to behave as if there is nothing wrong in the incomplete magic ":(top" that is not closed, isn't it? -- 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
Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
On 3/7/13, Junio C Hamano wrote: > This did not error out for me, though. > > $ cd t && git ls-files ":(top" No error message at all? Hm, maybe in your case, the byte after the end of string happens to be '\0' and the loop ended by chance? git doesn't crash for me, but it generates this error: $ git ls-files ":(top" fatal: Invalid pathspec magic 'LS_COLORS=' in ':(top' The loop runs for a second time after parsing "top", and copyfrom now points to the byte after ":(top", which is coming from argv. And in my distribution/platform, it looks like the envp, the third param of main(), is packed right after the argv strings, because: $ env | head -n 1 LS_COLORS= -- 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
Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
Andrew Wong writes: > On 3/7/13, Junio C Hamano 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 > string. This did not error out for me, though. $ cd t && git ls-files ":(top" -- 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
Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
On 3/7/13, Junio C Hamano 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 string. 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... Andrew -- 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
Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
Andrew Wong writes:
> The previous code was assuming length ends at either `)` or `,`, and was
> not handling the case where strcspn returns length due to end of string.
> So specifying ":(top" as pathspec will cause the loop to go pass the end
> of string.
Thanks.
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?
> Signed-off-by: Andrew Wong
> ---
> setup.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 1dee47e..f4c4e73 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -207,9 +207,11 @@ static const char *prefix_pathspec(const char *prefix,
> int prefixlen, const char
>*copyfrom && *copyfrom != ')';
>copyfrom = nextat) {
> size_t len = strcspn(copyfrom, ",)");
> - if (copyfrom[len] == ')')
> + if (copyfrom[len] == '\0')
> nextat = copyfrom + len;
> - else
> + else if (copyfrom[len] == ')')
> + nextat = copyfrom + len;
> + else if (copyfrom[len] == ',')
> nextat = copyfrom + len + 1;
> if (!len)
> continue;
--
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
