Re: [PATCH v2 4/5] mailinfo: strip quoted CR on users' wish

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2021, 04:27 UTC
Message-ID: <xmqqa6p94xgn.fsf@gitster.g>
In-Reply-To: <01d4a4853b8a0b6911a2d7773f836620566b4293.1620148732.git.congdanhqx@gmail.com>

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

Show 12 quoted lines

> 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.