[vlc-devel] [PATCH] modules: use 16-bit ints for option counts

Rémi Denis-Courmont remi at remlab.net
Wed Sep 30 10:52:21 CEST 2020


Hi,

When I manipulate the byte size of an in -memory object, or the element count of an in-memory array, I use size_t. I know then that I don't have to worry about overflow, that a reference will be size_t*, that the format string modifier is z.

I have enough other potential problems to worry about when reading or writing code.

Le 29 septembre 2020 22:09:48 GMT+03:00, Lyndon Brown <jnqnfe at gmail.com> a écrit :
>On Tue, 2020-09-29 at 18:09 +0300, Rémi Denis-Courmont wrote:
>> Le tiistaina 29. syyskuuta 2020, 2.56.18 EEST Lyndon Brown a écrit :
>> > > Which is exactly the current situation. With size_t, you can't
>> > > overflow.
>> > 
>> > Who says I'd not tested it?
>> 
>> Most error paths are not tested, or only tested once when the code is
>> first 
>> written. I'm not interesting in arguing about this broadly accepted
>> notion.
>
>Granted.
>
>But both changes, the size change and catching a runaway series of
>creation requests, whichever or both you're referring to, are rather
>trivial to understand and follow, to be confident in. I don't think
>such concern is warranted here.
>
>I spent a lot of time exploring the option and plugin descriptor
>handling areas of the codebase both in terms of the Rust conversion
>project and in terms of a bunch of work pending submission (per stuff
>beneath it in the big patch tree gradually getting processed). This
>isn't just a random tweak without understanding of how this stuff is
>interacted with throughout the plugin descriptor and option handling
>code, I've looked and understood and carefully made changes.
>
>_______________________________________________
>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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200930/a90adb1f/attachment.html>


More information about the vlc-devel mailing list