<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>By the way, if you add a destroy function, you need to add a Create one.<br></div><div>Like this one:<br></div><div>vlc_dec_owner_Create(vlc_object_t *parent, size_t owner_size, const struct decoder_owner_callbacks *);<br></div><div><br></div><div>On Tue, Feb 19, 2019, at 10:09, Rémi Denis-Courmont wrote:<br></div><blockquote type="cite" id="fastmail-quoted"><div>No. I refer to the general case, to the mess that was some of VLC code way back, and to your proposal. It's all the same: it reliably hide bugs in single thread, making code fail silently (as Thomas pointed out), and it unreliably works around races, making them nigh-impossible to debug.<br></div><div><br></div><div>Either way, it makes debugging miserable.<br></div><div><br></div><div class="fastmail-quoted-gmail_quote"><div>Le 19 février 2019 11:02:27 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:0pt;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="fastmail-quoted-gmail_quote"><pre class="fastmail-quoted-k9mail"><div>Again you're talking about defensive programming in general. I agreed <br></div><div>already in many cases it's probably wrong. I don't think it's the case here.<br></div><div><br></div><div>On 19/02/2019 09:59, Rémi Denis-Courmont wrote:<br></div><blockquote style="margin-top:0pt;margin-right:0pt;margin-bottom:1ex;margin-left:0.8ex;border-left-color:rgb(114, 159, 207);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="fastmail-quoted-gmail_quote"><div> You are doing the exact same mistake as Jean-Paul Saman when he <br></div><div> sprinkled defensive programming over the code base: incorrectly <br></div><div> assuming that VLC is single-threaded.<br></div><div><br></div><div> Le 19 février 2019 10:44:38 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> <br></div><div> a écrit :<br></div><div><br></div><div> There cannot be any double-free occurring in my implementation. That's<br></div><div> the class of bugs it removes.<br></div><div><br></div><div> It will of course not solve use after free issues. And I don't see how<br></div><div> it makes it easier/harder to track such issues.<br></div><div><br></div><div> On 19/02/2019 09:02, Rémi Denis-Courmont wrote:<br></div><div><br></div><div> This does not remove any class of bug. If there is a<br></div><div> use-after-free, it still fails or hides the bug (depending if<br></div><div> the use checks for NULL or not). If there is a double free<br></div><div> race, it hides the bug in most cases making it very hard to<br></div><div> reproduce, all the while not actually fixing it. Le 19 février<br></div><div> 2019 09:13:36 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a<br></div><div> écrit : On 19/02/2019 08:03, Jean-Baptiste Kempf wrote: Hello,<br></div><div> On Tue, 19 Feb 2019, at 08:01, Steve Lhomme wrote: I really<br></div><div> prefer having a crash (via assert/ASAN) when a client is<br></div><div> misusing an API (calling Destroy with a freed pointer) instead<br></div><div> of ignoring it. This is true when calling Destroy twice is a<br></div><div> bug. It isn't with this Then assert() it. I'm not sure I'm<br></div><div> following. Would you assert when calling decoder_Destroy()<br></div><div> with a NULL decoder (meaning it doesn't exist at all, not even<br></div><div> been through decoder_Init) ? Or in the solution I removed<br></div><div> where you'd call decoder_Destroy() with a holder than has been<br></div><div> emptied, which is not a bug at all. Or you mean assert when<br></div><div> decoder_Destroy() is passed an already freed pointer ? In<br></div><div> which case no assert will help detect a double free. As a more<br></div><div> general remark, I think it's odd that rather than removing a<br></div><div> class of bugs, we prefer to keep it and rely on tools to find<br></div><div> them for us, when they eventually occur. This is not a libVLC<br></div><div> API, where you need to deal with invalid input, and where<br></div><div> assert is not enough. -- Jean-Baptiste Kempf - President +33<br></div><div> 672 704 734<hr> vlc-devel mailing list To unsubscribe or modify your<br></div><div> subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><hr> vlc-devel mailing list To unsubscribe or modify your<br></div><div> subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a> -- Envoyé de<br></div><div> mon appareil Android avec Courriel K-9 Mail. Veuillez excuser<br></div><div> ma brièveté.<hr> vlc-devel mailing list To unsubscribe or modify your<br></div><div> subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a> <hr> vlc-devel mailing list<br></div><div> To unsubscribe or modify your subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div><div><br></div><div><br></div><div> -- <br></div><div> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez <br></div><div> excuser ma brièveté.<hr> vlc-devel mailing list<br></div><div> To unsubscribe or modify your subscription options:<br></div><div> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></blockquote><div><hr>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></div></pre></blockquote></div><div><br></div><div>-- <br></div><div>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. <br></div><div>_______________________________________________<br></div><div>vlc-devel mailing list<br></div><div>To unsubscribe or modify your subscription options:<br></div><div>https://mailman.videolan.org/listinfo/vlc-devel<br></div></blockquote><div><br></div></body></html>