Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> 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.
> 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.
