Hi, On Sun, Jun 4, 2017 at 6:32 AM, Nicolas George <geo...@nsup.org> wrote:
> Le quintidi 15 prairial, an CCXXV, James Almer a écrit : > > On 6/3/2017 9:25 PM, Michael Niedermayer wrote: > > I see EINVAL more fit as an error for example if src or dst are NULL, > > something that would actually be an invalid argument. > > We don't currently check that, for that matter. Maybe we should... > > This kind of case, I call "obviously invalid use of the API", and I > think in these cases, an immediate crash is way better than an error > code. The crash is already what happens here, since par and codec are > immediately dereferenced. An av_assert0() would make it clearer. > > The same goes for every cases where passing NULL makes no sense, passing > an invalid value where a small set of enumerated values / flags is > expected (42 instead of SEEK_SET is an obvious example), or calling a > amath function outside a simple interval. > > We may want to introduce something like av_assert_api() to have the > failure message tell explicitly that the crash is caused by a bug in the > application rather than the library. This reminds me of g_return_val_if_fail in glib, and in some situations it's quite sensible and helpful. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
