On Mon, Mar 16, 2015 at 01:26:04PM +0100, Stefano Sabatini wrote: > On date Monday 2015-03-16 11:11:55 +0100, Clément Bœsch encoded: > > On Mon, Mar 16, 2015 at 11:05:12AM +0100, Stefano Sabatini wrote: > > > On date Monday 2015-03-16 11:00:12 +0100, Stefano Sabatini encoded: > > > > On date Sunday 2015-03-15 15:15:34 +0100, Clément Bœsch encoded: > > > [...] > > > > > To elaborate on this, the bug here is referring to an allocation > > > > > check not > > > > > done in the caller (there are many currently since I'm just > > > > > introducing > > > > > the error handling). > > > > > > > > I won't block this patch, but getting a crash in a specified point of > > > > the program is more useful than failing with this: > > > > > > > > > > > A bug occurred somewhere > > > > > > Now this is not correct, it should be: > > > there is a bug somewhere > > > > > > (since bug don't "occurr" but stay/are). Now that (the presence of a > > > "bug") is not even a good reason to fail a program, it should had been > > > named something more meaningful like "unexpected condition" (but again > > > - for that a crash or an assert is just more useful to the > > > programmer). > > > > We are talking about a crash non programmer would get. If you want, I can > > add an av_log message saying that the filter is buggy. I just don't want > > to create dozens of potential crashes when we know this can be NULL in the > > current state. Asserting on the result of malloc feels just wrong. > > What about asserting in the callee if the argument is NULL?
Well that's what you are proposing since the beginning. I'm not sure I get your point (nor you getting mine...) Anyway, patch applied. I can add still add the av_log() if you want to. -- Clément B.
pgpQv803Yja6n.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
