From: Don Zickus <dzickus@redhat.com>
To: git@vger.kernel.org
Cc: Don Zickus <dzickus@redhat.com>
Subject: [PATCH] Allow emails with boundaries to work again [v2]
Date: Thu, 14 Aug 2008 11:35:42 -0400 [thread overview]
Message-ID: <1218728142-23780-1-git-send-email-dzickus@redhat.com> (raw)
Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
The reason was after handling the end of the boundary the code tried to look
for another boundary. Because the boundary list was empty, dereferencing
the pointer to the top of the boundary caused the program to go boom.
The fix is to check to see if the list is empty and if so go on its merry
way instead of looking for another boundary.
I also fixed a couple of increments and decrements that didn't look correct
relating to content_top.
The boundary test case was updated to catch future problems like this again.
Signed-Off-by: Don Zickus <dzickus@redhat.com>
---
Junio,
I modified the patch more to your liking, I think. You inquired about
returning after failing from find_boundary() and I gave you a not so correct
answer. Once I re-read the code this morning (minus a screaming kid in the
background), I realized it was easy to do and more correct.
I also figured out why the boundary test case didn't catch this. Apparently
find_boundary() went to read another line and found none, so it returned 0.
Adding an empty line to sample.mbox, caused git-mailinfo to segfault like
the way I saw it. My fix allows everything to work again.
Cheers,
Don
---
builtin-mailinfo.c | 6 +++---
t/t5100/sample.mbox | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 6ae2bf3..207d0ef 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -175,7 +175,7 @@ static void handle_content_type(struct strbuf *line)
message_type = TYPE_OTHER;
if (slurp_attr(line->buf, "boundary=", boundary)) {
strbuf_insert(boundary, 0, "--", 2);
- if (content_top++ >= &content[MAX_BOUNDARIES]) {
+ if (++content_top > &content[MAX_BOUNDARIES]) {
fprintf(stderr, "Too many boundaries to handle\n");
exit(1);
}
@@ -603,7 +603,7 @@ static void handle_filter(struct strbuf *line);
static int find_boundary(void)
{
while (!strbuf_getline(&line, fin, '\n')) {
- if (is_multipart_boundary(&line))
+ if (*content_top && is_multipart_boundary(&line))
return 1;
}
return 0;
@@ -626,7 +626,7 @@ again:
/* technically won't happen as is_multipart_boundary()
will fail first. But just in case..
*/
- if (content_top-- < content) {
+ if (--content_top < content) {
fprintf(stderr, "Detected mismatched boundaries, "
"can't recover\n");
exit(1);
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index d7ca79b..4bf7947 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -500,3 +500,4 @@ index 3e5fe51..aabfe5c 100644
1.6.0.rc2
--=-=-=--
+
--
1.5.5.1
next reply other threads:[~2008-08-14 15:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 15:35 Don Zickus [this message]
2008-08-18 5:42 ` [PATCH] Allow emails with boundaries to work again [v2] Kevin Ballard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218728142-23780-1-git-send-email-dzickus@redhat.com \
--to=dzickus@redhat.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).