[FFmpeg-devel] [PATCH 9/9] boadec: prevent overflow during block alignment calculation

[Andreas Cadhalpun]

On 30.01.2017 17:17, Ronald S. Bultje wrote:
> On Sun, Jan 29, 2017 at 7:37 PM, Andreas Cadhalpun <
> andreas.cadhalpun at googlemail.com> wrote:
> 
>> On 29.01.2017 04:46, Ronald S. Bultje wrote:
>>> Hm ... So I guess I wasn't clear about this, but the reason I didn't
>> reply
>>> to other patches with log messages was not because I'm OK with, but
>> simply
>>> to keep the discussion contained in a single thread and not spam the
>> list.
>>> I'd prefer if the log msg disappeared from all fuzz-only checks...
>>
>> Being a "fuzz-only check" is not a well-defined concept. Anything a fuzzer
>> does could in principle also happen due to file corruption.
> 
> 
> Please stop already. This is ridiculous.

Please don't ignore the rest of my argument nor laugh at it.

> Error messages are supposed to help solve a problem. A corrupt file isn't
> solvable.

It can be solved by restoring a backup, for example.

> No error message can help. So why bother informing the user?

To give the user some clue what's wrong. It's impossible to tell
in advance, whether or not that will actually help him.

> "Channel count too large" is the same as "fluffybuzz whackabit
> mackahooloo".

It obviously isn't: Unlike the latter, the former can be understood
by most English speaking persons.

Also the log message added here was "Too many channels", which already
had 9 occurrences in the code base and which is quite similar to
"Too many invisible frames", which you added.
It is completely arbitrary that you bikeshed my patches, while you
apparently have no problem with those.

> There is no action associated with the message that can help
> solve it. This is different from "encryption key missing, please use the
> option -key value to specify" for encrypted content.

Almost no log message in the ffmpeg code base contains a direct action.
Do you want to remove all other log messages?

> All we're doing is growing source and binary size and code complexity, and
> we do so without any apparent benefit. I just don't think that's a great
> approach.

Marton proposed a way to mitigate this [1], but you haven't commented
on it so far.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206327.html