[FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Soft
> Works
> Sent: Wednesday, February 2, 2022 11:19 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Oneric
> > Sent: Wednesday, February 2, 2022 6:03 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}:
> fix
> > handling of backslashes
> >
> > It appears my previous mail has been interpreted as some sort of
> > attack
> > against you; this is not the case. I am sorry for creating such a
> > misunderstanding.
> 
> Don't know who said that, but I don't feel attacked. It's about
> technical
> details and opinions about it. All good.
> 
> > The mail was merely meant to clear up the misconception that it
> would
> > be
> > impossible to send mixed line-endings via mail due to some SMTP
> > property
> > using some illustrative examples from the current thread.
> > (I have no idea how SMTP works in detail)
> 
> Where did you see such misconception? I think almost everybody knows
> that this is doable over SMTP in some way, and there are in
> fact many ways to do this, even when it would be as stupid like
> attaching
> as zip archive.
> 
> It's never been a matter of SMTP. It's the GIT tooling in the context
> of
> "patch-over-SMTP" transport and the way it is using plain-ascii-text
> e-mails for this purpose. IMO, this is a design flaw or just a bug
> when git-send-email and format-patch are creating output with
> transfer-encodings
> 7bit/8bit but mixed EOLs.
> 
> I suppose this is due to the tendency of GIT to consider text file
> basically
> as files with lines of text where the line endings are exchangeable
> and
> rather a platform detail than part of the text file's content.
> And text files with mixed line endings are an accidental side effect
> of
> multi-platform work and the endings can be re-unified at any time.
> That's also the reason why format-patch cannot warn, because
> bazillions
> of code files exist which have mixed EOLs (accidentally and
> exchangeable).
> 
> Yes, yes yes - don't need to respond that GIT can handle those cases
> flawlessly and precisely when configured appropriately (and when not
> using the e-mail features). That goes without saying.
> I'm just speculating about history, why it might have happened that
> it doesn't work flawlessly when using e-mail.
> 
> Via e-mail, it only works when using base64 encoding like you said,
> but this had only been added at a later time and wasn't part of the
> original functionality.

Haha, I almost forgot to get to my own point..

From that situation above, I would conclude that at least at an earlier
time, the git developers (when asked about a case like the ffmpeg ref
files) might have argued that such files with mixed EOL where the 
individual EOLs also form a relevant part of the 
content - are not meant to be handled as text, but as binary
files (either) or at to use binary diffs when being send via e-mail.
.

sw