git am with MIME

git am with MIME

[Lea Wiemann]

There's still a problem with git am on the current next branch (which
includes the recent "mailinfo: re-fix MIME multipart boundary parsing"
patch):

$ wcat -q
'http://article.gmane.org/gmane.comp.version-control.git/91305/raw' | git am
fatal: `pos + len' is too far after the end of the buffer
$

It seems to be because of the (unusual?) way the patch uses MIME.  Just
wanted to post this so it doesn't get lost.

-- Lea

Re: git am with MIME

[Jeff King]

On Tue, Aug 19, 2008 at 05:50:14PM +0200, Lea Wiemann wrote:

> $ wcat -q
> 'http://article.gmane.org/gmane.comp.version-control.git/91305/raw' | git am
> fatal: `pos + len' is too far after the end of the buffer
> $
> 
> It seems to be because of the (unusual?) way the patch uses MIME.  Just
> wanted to post this so it doesn't get lost.

It's the From header actually. The patch below should fix it (though it
sure makes that line of code ugly -- improvements are welcome).

-- >8 --
mailinfo: avoid violating strbuf assertion

In handle_from, we calculate the end boundary of a section
to remove from a strbuf using strcspn like this:

  el = strcspn(buf, set_of_end_boundaries);
  strbuf_remove(&sb, start, el + 1);

This works fine if "el" is the offset of the boundary
character, meaning we remove that character. But if the end
boundary didn't match (that is, we hit the end of the string
as the boundary instead) then we want just "el".

This manifested itself when we got a 'From' header that had
just an email address with nothing else in it (the end of
the string was the end of the address, rather than, e.g., a
trailing '>' character).
---
 builtin-mailinfo.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 26d3e5d..e890f7a 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -107,7 +107,7 @@ static void handle_from(const struct strbuf *from)
 	el = strcspn(at, " \n\t\r\v\f>");
 	strbuf_reset(&email);
 	strbuf_add(&email, at, el);
-	strbuf_remove(&f, at - f.buf, el + 1);
+	strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
 
 	/* The remainder is name.  It could be "John Doe <john.doe@xz>"
 	 * or "john.doe@xz (John Doe)", but we have removed the
-- 
1.6.0.96.g2fad1.dirty

Re: git am with MIME

[Alex Riesen]

Jeff King, Tue, Aug 19, 2008 19:07:31 +0200:
> On Tue, Aug 19, 2008 at 05:50:14PM +0200, Lea Wiemann wrote:
> @@ -107,7 +107,7 @@ static void handle_from(const struct strbuf *from)
>  	el = strcspn(at, " \n\t\r\v\f>");
>  	strbuf_reset(&email);
>  	strbuf_add(&email, at, el);
> -	strbuf_remove(&f, at - f.buf, el + 1);
> +	strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
>  

 +	strbuf_remove(&f, at - f.buf, el + !!at[el]);

(Some people'll kill me for that :)

Re: git am with MIME

[Jeff King]

On Wed, Aug 20, 2008 at 09:57:34PM +0200, Alex Riesen wrote:

> > -	strbuf_remove(&f, at - f.buf, el + 1);
> > +	strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
>  +	strbuf_remove(&f, at - f.buf, el + !!at[el]);
> 
> (Some people'll kill me for that :)

Ewwww. ;)

-Peff

Re: git am with MIME

[Eric Raible]

Alex Riesen <raa.lkml <at> gmail.com> writes:

> 
> Jeff King, Tue, Aug 19, 2008 19:07:31 +0200:
> > On Tue, Aug 19, 2008 at 05:50:14PM +0200, Lea Wiemann wrote:
> > @@ -107,7 +107,7 @@ static void handle_from(const struct strbuf *from)
> >  	el = strcspn(at, " \n\t\r\v\f>");
> >  	strbuf_reset(&email);
> >  	strbuf_add(&email, at, el);
> > -	strbuf_remove(&f, at - f.buf, el + 1);
> > +	strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
> >  
> 
>  +	strbuf_remove(&f, at - f.buf, el + !!at[el]);
> 
> (Some people'll kill me for that :)

And why shouldn't they when:

	strbuf_remove(&f, at - f.buf, el + (at[el] != 0));

is infinitely better in every possible way? ;)

Re: git am with MIME

[Alex Riesen]

2008/8/21 Eric Raible <raible@gmail.com>:
> Alex Riesen <raa.lkml <at> gmail.com> writes:
>> (Some people'll kill me for that :)
>
> And why shouldn't they when:
>
>        strbuf_remove(&f, at - f.buf, el + (at[el] != 0));
>
> is infinitely better in every possible way? ;)

Because that's just as ugly as "?:", brackets and all