On Sat, Mar 15, 2014 at 06:19:08AM +0530, Shubham Chaudhary wrote:

> From c422507408824403ed18e89ec0bbc32b8764e09c Mon Sep 17 00:00:00 2001

You can drop this line; it's just part of the mbox format.

> From: Shubham Chaudhary <shubham.chaudh...@kdemail.net>
> Date: Sat, 15 Mar 2014 05:56:18 +0530
> Subject: [PATCH] [GSoC] Use strchrnul to save additional scan of string

And these are redundant with your mail headers. You can drop all of them.

Your patch also appears to be whitespace-damaged (it looks like extra
wrawpping). Consider using git-send-email, which takes care of all of
these issues.

> diff --git a/archive.c b/archive.c
> index 346f3b2..d196215 100644
> --- a/archive.c
> +++ b/archive.c
> @@ -259,8 +259,8 @@ static void parse_treeish_arg(const char **argv,
>       /* Remotes are only allowed to fetch actual refs */
>       if (remote) {
>               char *ref = NULL;
> -             const char *colon = strchr(name, ':');
> -             int refnamelen = colon ? colon - name : strlen(name);
> +             const char *colon = strchrnul(name, ':');
> +             int refnamelen = colon - name;

This one is pretty straightforward, as we do not need ever look at
"colon" after this. But this one:

> diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
> index 2c3cd8e..f901cf3 100644
> --- a/builtin/mailinfo.c
> +++ b/builtin/mailinfo.c
> @@ -902,12 +902,8 @@ static void output_header_lines(FILE *fout, const
> char *hdr, const struct strbuf
>  {
>       const char *sp = data->buf;
>       while (1) {
> -             char *ep = strchr(sp, '\n');
> -             int len;
> -             if (!ep)
> -                     len = strlen(sp);
> -             else
> -                     len = ep - sp;
> +             char *ep = strchrnul(sp, '\n');
> +             int len = ep - sp;
>               fprintf(fout, "%s: %.*s\n", hdr, len, sp);
>               if (!ep)
>                       break;

...does not look right. Before your patch, "ep" pointed to a newline, or
NULL if we did not find one. After the fprintf, we try to break out of
the loop if we did not find a newline by checking "!ep". But that will
never trigger after your patch, and we loop forever reading bogus data
past the end of the string.

I didn't check the other sites; this might be the only problematic one,
but each one needs to be examined by hand. Please double-check the
result by running "make test", which does find this bug.

-Peff
--
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