Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Роман Донченко" <dpb@xxxxxxxxxxxxxx>
Jeff King <peff@xxxxxxxx> писал в своём письме Sun, 07 Dec 2014 12:18:59 +0300:

On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote:

The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).

Thanks. Both patches look good to me, and I'd be happy to have them
applied as-is. I wrote a few comments below, but in all cases I think I
convinced myself that what you wrote is best.

I had the same concerns myself, and eventually convinced myself of the same. :-)

One final note on this bit of code: if there are multiple encoded words, we grab the $charset from the final encoded word, and never report the
earlier charsets. Technically they do not all have to be the same
(rfc2047 even has an example where they are not). I think we can dismiss
this, though, as:

1. It was like this before your patches (we might have seen multiple
     non-adjacent encoded words; you're just handling adjacent ones),
     and nobody has complained.

  2. Using two separate encodings in the same header is sufficiently
     ridiculous that I can live with us not handling it properly.

Yeah, that bugs me as well. But I think handling multiple encodings would require substantial reworking of the code, so I chickened out (with the same excuses :-)).

Would that be worth a terse comment in the documentation change part of the patch?
"Multiple  (RFC2047) encodings are not supported.",
or would that be bike shed noise.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]