[vlc-devel] [vlc-commits] decoder: add Destroy helper function for decoder owners
Steve Lhomme
robux4 at ycbcr.xyz
Tue Feb 19 10:02:27 CET 2019
Again you're talking about defensive programming in general. I agreed
already in many cases it's probably wrong. I don't think it's the case here.
On 19/02/2019 09:59, Rémi Denis-Courmont wrote:
> You are doing the exact same mistake as Jean-Paul Saman when he
> sprinkled defensive programming over the code base: incorrectly
> assuming that VLC is single-threaded.
>
> Le 19 février 2019 10:44:38 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz>
> a écrit :
>
> There cannot be any double-free occurring in my implementation. That's
> the class of bugs it removes.
>
> It will of course not solve use after free issues. And I don't see how
> it makes it easier/harder to track such issues.
>
> On 19/02/2019 09:02, Rémi Denis-Courmont wrote:
>
> This does not remove any class of bug. If there is a
> use-after-free, it still fails or hides the bug (depending if
> the use checks for NULL or not). If there is a double free
> race, it hides the bug in most cases making it very hard to
> reproduce, all the while not actually fixing it. Le 19 février
> 2019 09:13:36 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a
> écrit : On 19/02/2019 08:03, Jean-Baptiste Kempf wrote: Hello,
> On Tue, 19 Feb 2019, at 08:01, Steve Lhomme wrote: I really
> prefer having a crash (via assert/ASAN) when a client is
> misusing an API (calling Destroy with a freed pointer) instead
> of ignoring it. This is true when calling Destroy twice is a
> bug. It isn't with this Then assert() it. I'm not sure I'm
> following. Would you assert when calling decoder_Destroy()
> with a NULL decoder (meaning it doesn't exist at all, not even
> been through decoder_Init) ? Or in the solution I removed
> where you'd call decoder_Destroy() with a holder than has been
> emptied, which is not a bug at all. Or you mean assert when
> decoder_Destroy() is passed an already freed pointer ? In
> which case no assert will help detect a double free. As a more
> general remark, I think it's odd that rather than removing a
> class of bugs, we prefer to keep it and rely on tools to find
> them for us, when they eventually occur. This is not a libVLC
> API, where you need to deal with invalid input, and where
> assert is not enough. -- Jean-Baptiste Kempf - President +33
> 672 704 734
> ------------------------------------------------------------------------
> vlc-devel mailing list To unsubscribe or modify your
> subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
> ------------------------------------------------------------------------
> vlc-devel mailing list To unsubscribe or modify your
> subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel -- Envoyé de
> mon appareil Android avec Courriel K-9 Mail. Veuillez excuser
> ma brièveté.
> ------------------------------------------------------------------------
> vlc-devel mailing list To unsubscribe or modify your
> subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
> ------------------------------------------------------------------------
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser ma brièveté.
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list