Re: Commits 12505, 12508, 12509, 12510
Petri Hintukainen <[email protected]> Fri, 14 Mar 2014 22:28:34 +0200
| Newsgroups | gmane.comp.video.xine.devel |
|---|---|
| Message-ID | <1394828914.5012.25.camel@ph-NF310> |
On to, 2014-03-13 at 00:51 +0100, Torsten Jager wrote:
> 12505:
> 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,
#else
char **values,
#endif
Yes, it is not pretty either ...
- Petri
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech