On Fri, Mar 30, 2007 at 02:19:42PM -0700, Junio C Hamano wrote:
> Don Zickus <dzickus@xxxxxxxxxx> writes:
>
> > Don't translate the patch to UTF-8, instead preserve the data as is. Also
> > allow overwriting the primary mail headers (addresses Linus's concern).
> >
> > I also revert a test case that was included in the original patch. Now it
> > makes sense why it was the way it was. :)
> >
> > Cheers,
> > Don
>
> Thanks. Sign-off would have been nice.
Doh. Sorry. Should I repost with fix below?
> This check_header is called from each multi-part boundary with
> overwrite=1, so if you have two parts and you have From: or
> Subject: in the multi-part header (not in-body), wouldn't they
> overwrite what we already have? That is not desired, I would
> think.
Hmm. I guess I never thought about that case. You are right, that check
can be changed to a zero (because the rfc2822 are checked elsewhere).
> > @@ -614,6 +614,7 @@ static int find_boundary(void)
> >
> > static int handle_boundary(void)
> > {
> > + char newline[]="\n";
> > again:
> > if (!memcmp(line+content_top->boundary_len, "--", 2)) {
> > /* we hit an end boundary */
> > @@ -628,7 +629,7 @@ again:
> > "can't recover\n");
> > exit(1);
> > }
> > - handle_filter("\n");
> > + handle_filter(newline);
> >
> > /* skip to the next boundary */
> > if (!find_boundary())
>
> These two hunks certainly do not hurt, but why? Is this about
> the constness of the first parameter to handle_filter() and its
> call chain?
Yeah, I SEGFAULT'd when trying to convert_to_utf8() a fixed string. :-)
Cheers,
Don
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html