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

Further - I could find no evidence for your claims that base64 encoding
would be chosen automatically depending on the content, neither is it
on by default.
There's an 'auto' mode which chooses between 7bit, 8bit and quoted-printable,
but not base64, which always needs to be specified explicitly (or set in
.gitconfig).

This is the way it is documented and I'm seeing exactly that documented
behavior on both Linux and Windows when testing with a mocked smtp server.


You had contradicted my statement that it would be desirable that format-patch
would be able to do base64 encoding as well, saying that this would be the 
task of a mail-client. This is not necessarily the case, though.
format-patch can generate patch e-mails with multipart-mime content, where 
the patch content is created as an attachment mime part. format-patch does
that with a transfer-encoding of 8bit, but it can't do it with base64 encoding.


(I'm stripping the rest of your reply as it is all covered above already)


Regards,
softworkz