[FFmpeg-devel] [PATCH 1/2] avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()

[Michael Niedermayer]

Hi Ronald

On Mon, Sep 18, 2017 at 09:11:39AM -0400, Ronald S. Bultje wrote:
> Hi Michael,
> 
> On Sun, Sep 17, 2017 at 8:15 PM, Michael Niedermayer <michael at niedermayer.cc
> > wrote:
> 
> > Iam happy to follow what the community prefers.
> >
> 
> Some don't like it, some don't care. I think everyone would be happy (and

I belive you did not ask the community. if so you cannot know what people
prefer. I think you extrapolate from 3 people who have been very vocal
about this to the whole community.


> thus the sum of happiness would increase) if you changed this to ff_dlog()
> or something along those lines.

Why do you keep arguing with me and not poll the community?

Iam happy to do what the majority prefers, but i do not know what
the majority prefers.


> 
> You say you want to code, so why not take the path of least resistance and
> move on?

If this is about changing one error message in one patch.
Ill just change it because id like to push this bugfix and argumentation
with you is quite time consuming and was so far in this case fruitless.
But the project should not be run by "its the path of least resistance
to comply with what i demand"

if OTOH what you want is establishing a rule about error messages.
No, one cannot do that without
1. writing the rule down
2. polling the comunity about it
3. including the rule in the policy so everyone, including new
   developers know about it.
This is a matter that needs a community decission first.
Also the codebase would become incresingly inconsistent without
this being agreed on by all and written down.


> Is this just about being right?

no, its very possible i and or you are wrong.


> Or do you really believe it's
> important to display an error message while fuzzing?

no. Its important when the user hits a bug/issue.
Developers can rebuild the tree with any debug flag, a user generally
cannot. But i belive we fundamentally disagree here.

The ones hit hardest with a wide spread removial of error messages
from the binary in a user build are probably the people dealing with
bug reports.
Its interresting to note that the people pushing for this removial
have quite some overlap with who has in the past attacked our most
active developer on the bug tracker. Iam sure its just a coincidence
but its still chilling to realize this.


> Or do you have actual
> evidence that this is an error path that will often occur in real-world
> files and where the provided error message helps our users resolve the
> issue that their valid (non-fuzzed, real-world) file is not playing back?

That yes, though its a very seperate thing. And part of what i
meant with "disagreeing" with you.

This error message here would trigger on a truncated frame/file.
Truncated files are common in the real world for all kinds of reasons.

This was found by a fuzzer but its not specific to fuzzing


Also, i very much would like to end this discussion, its a huge waste
of time for everyone.
If you dont want to have a community wide rule and dont want to
ask people outside of the group who dont like how error messages are
currently handled, then please stop asking me to change code.

Thank you

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170919/d7acc98a/attachment.sig>