On Thu, Oct 8, 2015 at 11:02 AM, wm4 <[email protected]> wrote: > 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).
I did not expect you to read it (and neither have I). I just wanted to point out the actual patch (which is at the very bottom). There, pthread_once is indeed checked. Regardless, I do not have a strong enough preference on this to oppose the patch. If you, Hendrik, and perhaps some others don't want to check the return value, then by all means go ahead. > _______________________________________________ > 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
