Thanks, Petri. Looks much better now.
And it raises that register_enum () question again.
What do you think?
People might still use older ffmpeg versions.
See my latest fixes.
What exactly is this good for (remember the main lists
are already fixed, and these additional syms are not
From: Petri Hintukainen <phintuka@us...> - 2014-03-14 20:49:06
On to, 2014-03-13 at 00:51 +0100, Torsten Jager wrote:
> Thanks, Petri. Looks much better now.
> And it raises that register_enum () question again.
> What do you think?
I wanted to change that before 1.2, but somehow I missed the deadline :)
And, changing it before 1.3 ... it might be safe, but I didn't do it
because of I wasn't sure (gcc generates some warnings) and because of it
does not actually fix anything.
My main concern was it might break C++ apps, but this conversion seems
to be valid in c++: g++ accepts assigning "char **" to "const char *
const *" without warnings while gcc generates a warning.
> Making them all "const char * const *" did work too
> (even with Kaffeine build/run), but that would be
> an API change.
Casting "char**" to "const char * const *" is safe. The opposite
(casting const away) is plain wrong and should be avoided when possible.
Adding const to parameters should be safe (backwards compatible), it
just adds promise that we won't change the data.
The problem here is that there may be applications implementing the
interface. In that case adding const is wrong. But, any application that
modifies those parameters would be broken anyway.
The interface itself is binary compatible with or without consts.
Maybe we could use something like
#if defined(XINE_COMPILE) || (XINE_VERSION_CODE >= 0x010300)
const char * const *values,
Yes, it is not pretty either ...