From: Eric Sunshine Date: Thu, 09 Jun 2016 06:51:30 GMT Subject: Re: [PATCH v4 4/6] send-email: create email parser subroutine Message-ID: In-Reply-To: <4c1dcf95-d8bb-4649-8980-fa947617b96e@grenoble-inp.org> On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT wrote: > On 06/08/2016 10:17 PM, Junio C Hamano wrote: >> Eric Sunshine writes: >>> An embedded CR probably shouldn't happen, but I'm not convinced that >>> folding it out is a good idea. I would think that you'd want to >>> preserve the header's value verbatim. If anything, I'd expect to see >>> the regex tightened to: >>> >>> s/\r?\n$//; >> >> Yes, that would be more sensible than silently removing \r in the >> middle which _is_ a sign of something funny going on. > > s/\r?\n$// looks fine. > > Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1]. > [1] * http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm You could certainly use s/\x0d?\x0a$// rather than s/\r?\n$// to be really robust, but I doubt it matters much today. The reason for using hex codes is that \r and \n will resolve to CR and LF in the local character encoding, and those may not be 0x0d and 0x0a, respectively. I believe the canonical example given in the Camel book was EBCIDIC in which \r is 0x0d, but \n is 0x25, not 0x0a as it is in ASCII.