Re: [PATCH v2 4/5] mailinfo: strip quoted CR on users' wish
From: Junio C Hamano <hidden>
Date: 2021-05-05 04:27:40
Đoàn Trần Công Danh [off-list ref] writes:
Subject: Re: [PATCH v2 4/5] mailinfo: strip quoted CR on users' wish
Again, perhaps
mailinfo: allow stripping quoted CR without warning
By the way, the previous one said "skip", but I do not think it was
skipping quoted CR, so its title was misleading. Perhaps
[3/5] mailinfo: allow squelching quoted CR warning
or something.
In previous changes, we've turned on warning for quoted CR in base64 or quoted-printable email messages. Some projects sees those quoted CR a lot and they know that it happens most of the time.
... a lot, they know that it happens most of the time, and they
know it always is harmless to behave as if these CRs are not
there.
The last sentence is an important precondition for the use of this
new option to be safe.
quoted hunk
diff --git a/mailinfo.c b/mailinfo.c index fe7ffd01d0..68f4eba72a 100644 --- a/mailinfo.c +++ b/mailinfo.c@@ -998,6 +998,11 @@ static void handle_filter_flowed(struct mailinfo *mi, struct strbuf *line, line->buf[len - 2] == '\r' && line->buf[len - 1] == '\n') { *have_quoted_cr = 1; + if (mi->quoted_cr == quoted_cr_strip) { + strbuf_setlen(line, len - 2); + strbuf_addch(line, '\n'); + len--;
The last one is beating a dead variable immediately before this function returns, even though it is good for consistency (i.e. there is an invaliant throughout the function that len is the number of bytes contained in line->buf[]). I am not sure what to think about this. I wish there weren't need for a separate len variable, with the need for this extra invariant. After all, strbuf already has such an invariant that is well understood by readers of this code (i.e. line->buf[]'s end is at line->len). For now, until we get rid of "len" from this function, let's leave the final decrement in to make it absolutely clear that we are aware of this extra invariant.