On Thu, 8 Oct 2015 10:56:16 -0400 Ganesh Ajjanagadde <[email protected]> wrote:
> On Thu, Oct 8, 2015 at 10:47 AM, Hendrik Leppkes <[email protected]> wrote: > > On Thu, Oct 8, 2015 at 4:35 PM, Ganesh Ajjanagadde <[email protected]> wrote: > >> On Thu, Oct 8, 2015 at 10:29 AM, Rémi Denis-Courmont <[email protected]> > >> wrote: > >>> Le 2015-10-08 17:21, Hendrik Leppkes a écrit : > >>>> > >>>> 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. > >>> > >>> > >>> That is not true. Plenty of projects check for errors there for debugging. > >> > >> Indeed, see for instance > >> http://www.libsdl.org/tmp/SDL/src/thread/pthread/SDL_sysmutex.c (SDL > >> mutexes) used by avplay. SDL mutex creation and destruction forwards > >> the error to avplay, where it is (currently) not being checked. > >> > > > > The real point of course is that pthread_once just cannot fail. The > > spec doesn't define any error codes, and the win32 implementation > > doesn't ever fail, the glibc impl never does, the musl impl never > > does, and at that point I gave up trying to figure out which > > implementations I should look for. > > If you want to litter the codebase with dead code, well, just go ahead. > > Maybe so currently, but there is no guarantee. In fact, it seems like > internally, glibc itself checks the return code: > https://patchwork.ozlabs.org/patch/482350/ That's a lot of text for something that doesn't matter, so I didn't read it. But they seem to be talking about C++ and UNIX signals, which don't matter at all in our case (or anyone who's sufficiently non-insane). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
