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. As for return checks being code noise, I disagree here - they serve a concrete purpose in the code. > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
