[PATCH 1/4] Improve message-id generation flow control for format-patch

[PATCH 1/4] Improve message-id generation flow control for format-patch

[Daniel Barkalow]

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
 builtin-log.c |   29 ++++++++++++++---------------
 1 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index dcc9f81..1f74d66 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -576,16 +576,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
 	o2->flags = flags2;
 }
 
-static void gen_message_id(char *dest, unsigned int length, char *base)
+static void gen_message_id(struct rev_info *info, char *base)
 {
 	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
 	const char *email_start = strrchr(committer, '<');
 	const char *email_end = strrchr(committer, '>');
-	if(!email_start || !email_end || email_start > email_end - 1)
+	struct strbuf buf;
+	if (!email_start || !email_end || email_start > email_end - 1)
 		die("Could not extract email from committer identity.");
-	snprintf(dest, length, "%s.%lu.git.%.*s", base,
-		 (unsigned long) time(NULL),
-		 (int)(email_end - email_start - 1), email_start + 1);
+	strbuf_init(&buf, 0);
+	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
+		    (unsigned long) time(NULL),
+		    (int)(email_end - email_start - 1), email_start + 1);
+	info->message_id = buf.buf;
 }
 
 static const char *clean_message_id(const char *msg_id)
@@ -626,8 +629,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	const char *in_reply_to = NULL;
 	struct patch_ids ids;
 	char *add_signoff = NULL;
-	char message_id[1024];
-	char ref_message_id[1024];
 
 	git_config(git_format_config);
 	init_revisions(&rev, prefix);
@@ -810,15 +811,13 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 		rev.nr = total - nr + (start_number - 1);
 		/* Make the second and subsequent mails replies to the first */
 		if (thread) {
-			if (nr == (total - 2)) {
-				strncpy(ref_message_id, message_id,
-					sizeof(ref_message_id));
-				ref_message_id[sizeof(ref_message_id)-1]='\0';
-				rev.ref_message_id = ref_message_id;
+			if (rev.message_id) {
+				if (rev.ref_message_id)
+					free((char *) rev.message_id);
+				else
+					rev.ref_message_id = rev.message_id;
 			}
-			gen_message_id(message_id, sizeof(message_id),
-				       sha1_to_hex(commit->object.sha1));
-			rev.message_id = message_id;
+			gen_message_id(&rev, sha1_to_hex(commit->object.sha1));
 		}
 		if (!use_stdout)
 			if (reopen_stdout(commit, rev.nr, keep_subject,
-- 
1.5.4.27.gf6864

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
>  builtin-log.c |   29 ++++++++++++++---------------
>  1 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index dcc9f81..1f74d66 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -576,16 +576,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
>  	o2->flags = flags2;
>  }
>  
> -static void gen_message_id(char *dest, unsigned int length, char *base)
> +static void gen_message_id(struct rev_info *info, char *base)
>  {
>  	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
>  	const char *email_start = strrchr(committer, '<');
>  	const char *email_end = strrchr(committer, '>');
> -	if(!email_start || !email_end || email_start > email_end - 1)
> +	struct strbuf buf;
> +	if (!email_start || !email_end || email_start > email_end - 1)
>  		die("Could not extract email from committer identity.");
> -	snprintf(dest, length, "%s.%lu.git.%.*s", base,
> -		 (unsigned long) time(NULL),
> -		 (int)(email_end - email_start - 1), email_start + 1);
> +	strbuf_init(&buf, 0);
> +	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> +		    (unsigned long) time(NULL),
> +		    (int)(email_end - email_start - 1), email_start + 1);
> +	info->message_id = buf.buf;

I wonder how the rule established by b315c5c (strbuf change: be
sure ->buf is never ever NULL) and at the beginning of strbuf.h
applies here.  I think the current implementation of strbuf
happens to allow this, and it is very handy.  Perhaps the rule
stated there should be loosened and allow copying the buf away
when you know you have stuff in there (i.e. ->buf != slopbuf).
Pierre, what do you think?

What the patch does itself is much nicer than the original.

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> >  builtin-log.c |   29 ++++++++++++++---------------
> >  1 files changed, 14 insertions(+), 15 deletions(-)
> >
> > diff --git a/builtin-log.c b/builtin-log.c
> > index dcc9f81..1f74d66 100644
> > --- a/builtin-log.c
> > +++ b/builtin-log.c
> > @@ -576,16 +576,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
> >  	o2->flags = flags2;
> >  }
> >  
> > -static void gen_message_id(char *dest, unsigned int length, char *base)
> > +static void gen_message_id(struct rev_info *info, char *base)
> >  {
> >  	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
> >  	const char *email_start = strrchr(committer, '<');
> >  	const char *email_end = strrchr(committer, '>');
> > -	if(!email_start || !email_end || email_start > email_end - 1)
> > +	struct strbuf buf;
> > +	if (!email_start || !email_end || email_start > email_end - 1)
> >  		die("Could not extract email from committer identity.");
> > -	snprintf(dest, length, "%s.%lu.git.%.*s", base,
> > -		 (unsigned long) time(NULL),
> > -		 (int)(email_end - email_start - 1), email_start + 1);
> > +	strbuf_init(&buf, 0);
> > +	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> > +		    (unsigned long) time(NULL),
> > +		    (int)(email_end - email_start - 1), email_start + 1);
> > +	info->message_id = buf.buf;
> 
> I wonder how the rule established by b315c5c (strbuf change: be
> sure ->buf is never ever NULL) and at the beginning of strbuf.h
> applies here.  I think the current implementation of strbuf
> happens to allow this, and it is very handy.  Perhaps the rule
> stated there should be loosened and allow copying the buf away
> when you know you have stuff in there (i.e. ->buf != slopbuf).
> Pierre, what do you think?
> 
> What the patch does itself is much nicer than the original.

  Why wouldn't you just use strbuf_detach ? I mean replacing:

+	info->message_id = buf.buf;

with:

+	info->message_id = strbuf_detach(&buf, NULL);

  isn't really hard to read, and has the nice side effect to prevent
errors that could happen in the future (like reusing buf and screwing
with info->message_id without noticing it). I'd rather stand on the safe
side here, it's more forward-compatible and idiot-proof[0].


  [0] Not that I believe git contributors are idiots, but I firmly
      believe in defensive programming when it doesn't impact
      performances. And I don't believe it would here.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Daniel Barkalow]

On Wed, 6 Feb 2008, Pierre Habouzit wrote:

> On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote:
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> > 
> > > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > > ---
> > >  builtin-log.c |   29 ++++++++++++++---------------
> > >  1 files changed, 14 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/builtin-log.c b/builtin-log.c
> > > index dcc9f81..1f74d66 100644
> > > --- a/builtin-log.c
> > > +++ b/builtin-log.c
> > > @@ -576,16 +576,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
> > >  	o2->flags = flags2;
> > >  }
> > >  
> > > -static void gen_message_id(char *dest, unsigned int length, char *base)
> > > +static void gen_message_id(struct rev_info *info, char *base)
> > >  {
> > >  	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
> > >  	const char *email_start = strrchr(committer, '<');
> > >  	const char *email_end = strrchr(committer, '>');
> > > -	if(!email_start || !email_end || email_start > email_end - 1)
> > > +	struct strbuf buf;
> > > +	if (!email_start || !email_end || email_start > email_end - 1)
> > >  		die("Could not extract email from committer identity.");
> > > -	snprintf(dest, length, "%s.%lu.git.%.*s", base,
> > > -		 (unsigned long) time(NULL),
> > > -		 (int)(email_end - email_start - 1), email_start + 1);
> > > +	strbuf_init(&buf, 0);
> > > +	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> > > +		    (unsigned long) time(NULL),
> > > +		    (int)(email_end - email_start - 1), email_start + 1);
> > > +	info->message_id = buf.buf;
> > 
> > I wonder how the rule established by b315c5c (strbuf change: be
> > sure ->buf is never ever NULL) and at the beginning of strbuf.h
> > applies here.  I think the current implementation of strbuf
> > happens to allow this, and it is very handy.  Perhaps the rule
> > stated there should be loosened and allow copying the buf away
> > when you know you have stuff in there (i.e. ->buf != slopbuf).
> > Pierre, what do you think?
> > 
> > What the patch does itself is much nicer than the original.
> 
>   Why wouldn't you just use strbuf_detach ? I mean replacing:
> 
> +	info->message_id = buf.buf;
> 
> with:
> 
> +	info->message_id = strbuf_detach(&buf, NULL);
> 
>   isn't really hard to read, and has the nice side effect to prevent
> errors that could happen in the future (like reusing buf and screwing
> with info->message_id without noticing it). I'd rather stand on the safe
> side here, it's more forward-compatible and idiot-proof[0].

Is it actually right to have buf go out of scope right after 
strbuf_detach()? It sort of looks like it would leak memory from buf.buf. 
I'm happy to do whatever the API wants there, and I didn't see anything to 
leave the struct as if strbuf_release were called, but with the string 
extracted for the caller.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

On Wed, Feb 06, 2008 at 10:10:30PM +0000, Daniel Barkalow wrote:
> On Wed, 6 Feb 2008, Pierre Habouzit wrote:
> 
> > On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote:
> > > I wonder how the rule established by b315c5c (strbuf change: be
> > > sure ->buf is never ever NULL) and at the beginning of strbuf.h
> > > applies here.  I think the current implementation of strbuf
> > > happens to allow this, and it is very handy.  Perhaps the rule
> > > stated there should be loosened and allow copying the buf away
> > > when you know you have stuff in there (i.e. ->buf != slopbuf).
> > > Pierre, what do you think?
> > > 
> > > What the patch does itself is much nicer than the original.
> > 
> >   Why wouldn't you just use strbuf_detach ? I mean replacing:
> > 
> > +	info->message_id = buf.buf;
> > 
> > with:
> > 
> > +	info->message_id = strbuf_detach(&buf, NULL);
> > 
> >   isn't really hard to read, and has the nice side effect to prevent
> > errors that could happen in the future (like reusing buf and screwing
> > with info->message_id without noticing it). I'd rather stand on the safe
> > side here, it's more forward-compatible and idiot-proof[0].
> 
> Is it actually right to have buf go out of scope right after 
> strbuf_detach()? It sort of looks like it would leak memory from buf.buf. 
> I'm happy to do whatever the API wants there, and I didn't see anything to 
> leave the struct as if strbuf_release were called, but with the string 
> extracted for the caller.

  err no, strbuf_detach gives you a pointer you are supposed to free()
later, and inits the strbuf passed as its argument to be used again,
though if you don't, you leak nothing.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

On Wed, Feb 06, 2008 at 10:53:35PM +0000, Pierre Habouzit wrote:
> On Wed, Feb 06, 2008 at 10:10:30PM +0000, Daniel Barkalow wrote:
> > On Wed, 6 Feb 2008, Pierre Habouzit wrote:
> > 
> > > On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote:
> > > > I wonder how the rule established by b315c5c (strbuf change: be
> > > > sure ->buf is never ever NULL) and at the beginning of strbuf.h
> > > > applies here.  I think the current implementation of strbuf
> > > > happens to allow this, and it is very handy.  Perhaps the rule
> > > > stated there should be loosened and allow copying the buf away
> > > > when you know you have stuff in there (i.e. ->buf != slopbuf).
> > > > Pierre, what do you think?
> > > > 
> > > > What the patch does itself is much nicer than the original.
> > > 
> > >   Why wouldn't you just use strbuf_detach ? I mean replacing:
> > > 
> > > +	info->message_id = buf.buf;
> > > 
> > > with:
> > > 
> > > +	info->message_id = strbuf_detach(&buf, NULL);
> > > 
> > >   isn't really hard to read, and has the nice side effect to prevent
> > > errors that could happen in the future (like reusing buf and screwing
> > > with info->message_id without noticing it). I'd rather stand on the safe
> > > side here, it's more forward-compatible and idiot-proof[0].
> > 
> > Is it actually right to have buf go out of scope right after 
> > strbuf_detach()? It sort of looks like it would leak memory from buf.buf. 
> > I'm happy to do whatever the API wants there, and I didn't see anything to 
> > leave the struct as if strbuf_release were called, but with the string 
> > extracted for the caller.
> 
>   err no, strbuf_detach gives you a pointer you are supposed to free()
> later, and inits the strbuf passed as its argument to be used again,
> though if you don't, you leak nothing.

  In fact, strbuf_detach is the rough equivalent of doing that:

  info->message_id = buf.buf;
  buf.buf = NULL;


  Except that it sets buf.buf to a magic place so that it's never NULL,
and that it also keeps the internal invariants in place. But after a
strbuf_detach, a strbuf doesn't holds any allocated memory anymore.
You'll see in many places in the code that
`return strbuf_detach(&sb, NULL)` is quite idiomatic, and the function
does exactly what it means "Please detach the memory allocated in that
buffer and give it to me".

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Daniel Barkalow]

On Wed, 6 Feb 2008, Pierre Habouzit wrote:

> On Wed, Feb 06, 2008 at 10:53:35PM +0000, Pierre Habouzit wrote:
> > On Wed, Feb 06, 2008 at 10:10:30PM +0000, Daniel Barkalow wrote:
> > > On Wed, 6 Feb 2008, Pierre Habouzit wrote:
> > > 
> > > > On Wed, Feb 06, 2008 at 08:31:08PM +0000, Junio C Hamano wrote:
> > > > > I wonder how the rule established by b315c5c (strbuf change: be
> > > > > sure ->buf is never ever NULL) and at the beginning of strbuf.h
> > > > > applies here.  I think the current implementation of strbuf
> > > > > happens to allow this, and it is very handy.  Perhaps the rule
> > > > > stated there should be loosened and allow copying the buf away
> > > > > when you know you have stuff in there (i.e. ->buf != slopbuf).
> > > > > Pierre, what do you think?
> > > > > 
> > > > > What the patch does itself is much nicer than the original.
> > > > 
> > > >   Why wouldn't you just use strbuf_detach ? I mean replacing:
> > > > 
> > > > +	info->message_id = buf.buf;
> > > > 
> > > > with:
> > > > 
> > > > +	info->message_id = strbuf_detach(&buf, NULL);
> > > > 
> > > >   isn't really hard to read, and has the nice side effect to prevent
> > > > errors that could happen in the future (like reusing buf and screwing
> > > > with info->message_id without noticing it). I'd rather stand on the safe
> > > > side here, it's more forward-compatible and idiot-proof[0].
> > > 
> > > Is it actually right to have buf go out of scope right after 
> > > strbuf_detach()? It sort of looks like it would leak memory from buf.buf. 
> > > I'm happy to do whatever the API wants there, and I didn't see anything to 
> > > leave the struct as if strbuf_release were called, but with the string 
> > > extracted for the caller.
> > 
> >   err no, strbuf_detach gives you a pointer you are supposed to free()
> > later, and inits the strbuf passed as its argument to be used again,
> > though if you don't, you leak nothing.
> 
>   In fact, strbuf_detach is the rough equivalent of doing that:
> 
>   info->message_id = buf.buf;
>   buf.buf = NULL;
> 
> 
>   Except that it sets buf.buf to a magic place so that it's never NULL,
> and that it also keeps the internal invariants in place. But after a
> strbuf_detach, a strbuf doesn't holds any allocated memory anymore.
> You'll see in many places in the code that
> `return strbuf_detach(&sb, NULL)` is quite idiomatic, and the function
> does exactly what it means "Please detach the memory allocated in that
> buffer and give it to me".

Ah, good. That's what I'll use, then.

	-Daniel
*This .sig left intentionally blank*

[PATCH 1/4] Improve message-id generation flow control for format-patch

[Daniel Barkalow]

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
 builtin-log.c |   29 ++++++++++++++---------------
 1 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 99d69f0..867cc13 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -575,16 +575,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
 	o2->flags = flags2;
 }
 
-static void gen_message_id(char *dest, unsigned int length, char *base)
+static void gen_message_id(struct rev_info *info, char *base)
 {
 	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
 	const char *email_start = strrchr(committer, '<');
 	const char *email_end = strrchr(committer, '>');
-	if(!email_start || !email_end || email_start > email_end - 1)
+	struct strbuf buf;
+	if (!email_start || !email_end || email_start > email_end - 1)
 		die("Could not extract email from committer identity.");
-	snprintf(dest, length, "%s.%lu.git.%.*s", base,
-		 (unsigned long) time(NULL),
-		 (int)(email_end - email_start - 1), email_start + 1);
+	strbuf_init(&buf, 0);
+	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
+		    (unsigned long) time(NULL),
+		    (int)(email_end - email_start - 1), email_start + 1);
+	info->message_id = strbuf_detach(&buf, NULL);
 }
 
 static const char *clean_message_id(const char *msg_id)
@@ -625,8 +628,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	const char *in_reply_to = NULL;
 	struct patch_ids ids;
 	char *add_signoff = NULL;
-	char message_id[1024];
-	char ref_message_id[1024];
 
 	git_config(git_format_config);
 	init_revisions(&rev, prefix);
@@ -809,15 +810,13 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 		rev.nr = total - nr + (start_number - 1);
 		/* Make the second and subsequent mails replies to the first */
 		if (thread) {
-			if (nr == (total - 2)) {
-				strncpy(ref_message_id, message_id,
-					sizeof(ref_message_id));
-				ref_message_id[sizeof(ref_message_id)-1]='\0';
-				rev.ref_message_id = ref_message_id;
+			if (rev.message_id) {
+				if (rev.ref_message_id)
+					free((char *) rev.message_id);
+				else
+					rev.ref_message_id = rev.message_id;
 			}
-			gen_message_id(message_id, sizeof(message_id),
-				       sha1_to_hex(commit->object.sha1));
-			rev.message_id = message_id;
+			gen_message_id(&rev, sha1_to_hex(commit->object.sha1));
 		}
 		if (!use_stdout)
 			if (reopen_stdout(commit, rev.nr, keep_subject,
-- 
1.5.4.1.1350.g2b9ee

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Daniel Barkalow wrote:

> diff --git a/builtin-log.c b/builtin-log.c
> index 99d69f0..867cc13 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -575,16 +575,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
>  	o2->flags = flags2;
>  }
>  
> -static void gen_message_id(char *dest, unsigned int length, char *base)
> +static void gen_message_id(struct rev_info *info, char *base)
>  {
>  	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
>  	const char *email_start = strrchr(committer, '<');
>  	const char *email_end = strrchr(committer, '>');
> -	if(!email_start || !email_end || email_start > email_end - 1)
> +	struct strbuf buf;
> +	if (!email_start || !email_end || email_start > email_end - 1)
>  		die("Could not extract email from committer identity.");
> -	snprintf(dest, length, "%s.%lu.git.%.*s", base,
> -		 (unsigned long) time(NULL),
> -		 (int)(email_end - email_start - 1), email_start + 1);
> +	strbuf_init(&buf, 0);
> +	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> +		    (unsigned long) time(NULL),
> +		    (int)(email_end - email_start - 1), email_start + 1);
> +	info->message_id = strbuf_detach(&buf, NULL);

With this last line, and...

> @@ -809,15 +810,13 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
>  		rev.nr = total - nr + (start_number - 1);
>  		/* Make the second and subsequent mails replies to the first */
>  		if (thread) {
> -			if (nr == (total - 2)) {
> -				strncpy(ref_message_id, message_id,
> -					sizeof(ref_message_id));
> -				ref_message_id[sizeof(ref_message_id)-1]='\0';
> -				rev.ref_message_id = ref_message_id;
> +			if (rev.message_id) {
> +				if (rev.ref_message_id)
> +					free((char *) rev.message_id);

... this one, you should make the message_id member of struct rev_info a 
"char *".  At least for this developer, "const char *" is a sign that the 
caller should clean up, and that the pointer _might_ point to a constant.

Ciao,
Dscho

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Daniel Barkalow]

On Mon, 18 Feb 2008, Johannes Schindelin wrote:

> Hi,
> 
> On Sun, 17 Feb 2008, Daniel Barkalow wrote:
> 
> > diff --git a/builtin-log.c b/builtin-log.c
> > index 99d69f0..867cc13 100644
> > --- a/builtin-log.c
> > +++ b/builtin-log.c
> > @@ -575,16 +575,19 @@ static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const cha
> >  	o2->flags = flags2;
> >  }
> >  
> > -static void gen_message_id(char *dest, unsigned int length, char *base)
> > +static void gen_message_id(struct rev_info *info, char *base)
> >  {
> >  	const char *committer = git_committer_info(IDENT_WARN_ON_NO_NAME);
> >  	const char *email_start = strrchr(committer, '<');
> >  	const char *email_end = strrchr(committer, '>');
> > -	if(!email_start || !email_end || email_start > email_end - 1)
> > +	struct strbuf buf;
> > +	if (!email_start || !email_end || email_start > email_end - 1)
> >  		die("Could not extract email from committer identity.");
> > -	snprintf(dest, length, "%s.%lu.git.%.*s", base,
> > -		 (unsigned long) time(NULL),
> > -		 (int)(email_end - email_start - 1), email_start + 1);
> > +	strbuf_init(&buf, 0);
> > +	strbuf_addf(&buf, "%s.%lu.git.%.*s", base,
> > +		    (unsigned long) time(NULL),
> > +		    (int)(email_end - email_start - 1), email_start + 1);
> > +	info->message_id = strbuf_detach(&buf, NULL);
> 
> With this last line, and...
> 
> > @@ -809,15 +810,13 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> >  		rev.nr = total - nr + (start_number - 1);
> >  		/* Make the second and subsequent mails replies to the first */
> >  		if (thread) {
> > -			if (nr == (total - 2)) {
> > -				strncpy(ref_message_id, message_id,
> > -					sizeof(ref_message_id));
> > -				ref_message_id[sizeof(ref_message_id)-1]='\0';
> > -				rev.ref_message_id = ref_message_id;
> > +			if (rev.message_id) {
> > +				if (rev.ref_message_id)
> > +					free((char *) rev.message_id);
> 
> ... this one, you should make the message_id member of struct rev_info a 
> "char *".  At least for this developer, "const char *" is a sign that the 
> caller should clean up, and that the pointer _might_ point to a constant.

It's sort of like that, in that this *is* the caller, and it's using 
gen_message_id to set it and cleaning it up, and it could put in a 
constant (in which case it would have to know this and not free it), but I 
agree that it's more suggestive of the right things as a "char *".

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 1/4] Improve message-id generation flow control for format-patch

[Johannes Schindelin]

Hi,

On Mon, 18 Feb 2008, Daniel Barkalow wrote:

> It's sort of like that, in that this *is* the caller,

Sorry, I should have been clearer.  It is all too easy to forget that 
reasoning and use rev_info->message_id in a different way, and then mix 
the code paths.

Ciao,
Dscho