[vlc-devel] [PATCHv3 05/13] input/item: add slave entries

Rémi Denis-Courmont remi at remlab.net
Tue May 17 18:45:18 CEST 2016

On Tuesday 17 May 2016 18:24:46 Thomas Guillem wrote:
> From: Benjamin Adolphi <b.adolphi at gmail.com>
> An input_item_t can now have a list of slaves. These slaves will be loaded
> when the input_item_t is loaded by an input_thread_t.
> Signed-off-by: Thomas Guillem <thomas at gllm.fr>
> ---
>  include/vlc_input_item.h | 51 ++++++++++++++++++++++++++++++++++++
>  src/input/item.c         | 68
> ++++++++++++++++++++++++++++++++++++++++++++++++ src/libvlccore.sym       |
>  3 +++
>  3 files changed, 122 insertions(+)
> diff --git a/include/vlc_input_item.h b/include/vlc_input_item.h
> index 9144fbb..01d5dc1 100644
> --- a/include/vlc_input_item.h
> +++ b/include/vlc_input_item.h
> @@ -37,6 +37,7 @@
>  #include <string.h>
>  typedef struct input_item_opaque input_item_opaque_t;
> +typedef struct input_item_slave input_item_slave;

Guys, this cannot continue. The time has come for The Greatest Decision the 
project will ever have to make:

Well, I think almost everybody is aware of the controversy surrounding _t. In 
principles, that suffix is reserved for the implementation (the compiler and 
run-time). However VLC and plenty of other programs violate that requirements 
because programmers can´t read specifications.

Personally I dislike type definitions identifiers that are not obviously a 
type identifer. It is too easy to conflict with variable and parameter 
identifiers. If it comes to that, I just use "struct" explicitly, and no 

That being said, I´m sure a lot of people prefer to just continue to use _t 
and violate the specifications. To their credits, I doubt the VLC code base 
will ever be cleaned up.

And on that note, I declare the bike shedding session open.

Rémi Denis-Courmont

More information about the vlc-devel mailing list