compiling with libvlc 2.0 in Windows

[ghell]

Compiling as C in visual studio 10 with 2.0.1 headers, anything that #includes libvlc.h.


In libvlc.h:

Code: Select all

static inline int64_t libvlc_delay(int64_t pts)

needs to be changed to

Code: Select all

static int64_t libvlc_delay(int64_t pts)

to work (no inline)



In libvlc_media_player.h:

Code: Select all

# include <stdbool.h>

needs to be changed to

Code: Select all

typedef int bool;

to work (no stdbool.h)


OR

Code: Select all

typedef void (*libvlc_audio_set_volume_cb)(void *data, float volume, bool mute);

needs to be changed to

Code: Select all

typedef void (*libvlc_audio_set_volume_cb)(void *data, float volume, int mute);

to work (bool to int)






These issues did not exist on older versions (e.g 1.1.11).

They are still there in the current git.

I assume they cause the same issues on other platforms but compiling as C99 solves them there (inline is C99 and stdbool.h just doesn't exist here). It seems like a strange hurdle to add for little to no benefit though.

[Rémi Denis-Courmont]

Your changes are not valid. bool is not the same as int, not in general and not even on any single platform.

You need a proper compiler.

[ghell]

Your changes are not valid. bool is not the same as int, not in general and not even on any single platform.

You need a proper compiler.

I was originally using an 8 bit integer as I assumed bool would be (smallest allocable unit), until I noticed that the typedef in stdbool.h, which is what you're using, actually uses a 32 bit integer.

Code: Select all

#define false 0 #define true 1 #define bool _Bool #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER) typedef int _Bool; #endif

bool is _Bool and _Bool is int (so bool is transitively int)


"true" and "false" can also cause problems if other values are used. For example:

Code: Select all

bool b; b = 2; if(b != true && b != false) { /* This actually runs, a bool can be neither true nor false */ }

while the standard convention for true in C is "not zero", and this is also what is used elsewhere (e.g. "do_pause: play/resume if zero, pause if non-zero")


There is also already an existing convention everywhere else in libvlc that uses an int in place of a bool, for example

Code: Select all

int libvlc_media_player_is_playing( libvlc_media_player_t *p_mi )

Code: Select all

int libvlc_media_player_is_seekable( libvlc_media_player_t *p_mi )

Code: Select all

void libvlc_media_player_set_pause( libvlc_media_player_t *p_mi, int paused )

This is the *only* place where the type "bool" is used, and it typedefs back to an int anyway, so there is not even any reason to use it. The code should also be consistent.

It only causes problems and does not improve anything.



"inline" does actually make a difference but this single keyword that occurs once in the source is the only thing that requires C99 to compile, and generally in C the same thing is achieved with preprocessor macros, while "inline" is generally only used in C++. From what I've heard "inline" also has a slightly different definition in gcc before and after C99 when it was added to the spec, which could cause unexpected changes in behaviour, although I don't know enough about this to talk in detail of the changes.


So, my changes are both valid and improvements. libvlc is as close to a perfect library as I have ever seen and I'd just like it to stay that way. These very minor changes have only existed since 2.0.x. There were no issues in 1.1.x

These problems affect anyone who tries to use libvlc.h (2.0.x) in their visual studio project (pretty much everyone who tries to use it on Windows). It is not just when compiling libvlc itself. I also suggested very small improvements rather than idly complaining without offering any suggestions. Hopefully I've given a reasonable argument for these suggestions and you will consider them.

Also, please try to be less condescending when you post.

[Rémi Denis-Courmont]

bool is _Bool and _Bool is not int. The ISO C specification contradicts you.

[RSATom]

why not just compile your sources as c++?

[ghell]

I'm surprised you're putting up so much resistance to defend an obvious flaw in the library that is easily fixed but whatever, it's your library and if you're going to start suddenly introducing silly problems like this now (likely just because you don't like people pointing them out to you), who am I to stop you?

why not just compile your sources as c++?

Because it happens when you #include libvlc.h in your existing project, not just when trying to compile libvlc. Not only should you not have to change your project to C++ in order to use a C library, in some cases you can't.

[Rémi Denis-Courmont]

I am surprised that you put up so much resistance to defend an obvious flaw in your compiler. C99 has been out for, hmm, 12 years. VLC has required it for over 5 years.

We do not change the LibVLC function prototypes. That would break binary compatibility for everybody (else) using sane compilers like, hmm... GCC, LLVM/clang, Intel, Sun...

[Jean-Baptiste Kempf]

I'm surprised you're putting up so much resistance to defend an obvious flaw in the library that is easily fixed but whatever, it's your library and if you're going to start suddenly introducing silly problems like this now (likely just because you don't like people pointing them out to you), who am I to stop you?

why not just compile your sources as c++?

Because it happens when you #include libvlc.h in your existing project, not just when trying to compile libvlc. Not only should you not have to change your project to C++ in order to use a C library, in some cases you can't.

libVLC is not a C library, it is a C99 library.