[FFmpeg-devel] [PATCH 4/5] avfilter/formats: proper error handling in ff_set_common_*() functions
u at pkh.me
Mon Mar 16 23:45:03 CET 2015
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel