On Thu, Oct 8, 2015 at 4:05 PM, Ganesh Ajjanagadde <[email protected]> wrote: > On Thu, Oct 8, 2015 at 9:55 AM, Hendrik Leppkes <[email protected]> wrote: >> Am 08.10.2015 15:27 schrieb "Derek Buitenhuis" <[email protected]>: >>> >>> On 10/8/2015 9:08 AM, Rémi Denis-Courmont wrote: >>> > I would assert and abort here. The most likely problems here are >>> > deadlocks (i.e. recursive initialization) and memory corruption (once >>> > ff_h264_vlc_init is garbage)... > > +1 > >>> >>> I initially had this since Hendrik's patch could fail, but that is no >>> longer the case. >>> >>> I have no strong opinion on what to do in the error case - you're screwed >>> regardless. >>> >> >> I would just not check the error, it should never be able to fail and >> reduces code noise. > > IMHO this should be checked - errors should almost always be handled. > A few exceptions include possibly signal handlers since they can do > very little anyway and are going to exit. Any function in regular code > that can fail will fail under certain circumstances - that is all that > is guaranteed by the API: http://linux.die.net/man/3/pthread_once. If > said function is guaranteed not to fail, the designers would not have > returned the int and would have made it void. >
pthread is a bit of a exception. All its functions can return errors, but the only time they would is if you pass in an invalid argument. No-one checks return values of pthread_mutex_lock, for example. Only functions worthy of checking are the related init functions. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
