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