Const…antine

No, this blog entry is not going to talk about the movie with Keanu Reeves (even though I did like it quite a lot); it’s just a summary of what I’ve been doing today.

With my break taking a break of its own, I’ve been trying to relax by working on other projects, contributing patches where I could, so that I at least I thought of something different for a while. I’ve been helping Luca fighting with warnings on FFmpeg and Nemesi, and then I decided to review a bit more xine-lib and xine-ui (unfortunately the double-click bug on xine-ui is still present in CVS.. my solution? People, just use gxine or Kaffeine or Totem or Codeine… just don’t use xine-ui, please!).

One interesting thing to do is to add const modifiers all over the structures and the function calls. Adding a const on a variable can (barely) help GCC’s heuristic, but has another big advantage: it stops you from directly changing its content through accessing that variable; it’s far from being 100% safety, but it’s a bit harder to screw things up.

One particular case is when returning a literal rom a function while the return type is set to char *: if you try to do anything over that literal that is not inspection, your program will easily blow up; xine-lib was doing that a lot so I decided to fix it as much as I could.. it’s not yet 100% fixed, as there is at least one place where a string array is returned as a constant string array and GCC warns you about it, but I’m not yet sure if that is a valid warning or just an error in GCC’s heuristic.

The result of the day is a lot of cod changed in xine’s CVS, and a very little change was visible at runtime because of it; it is an extra safety though, which users may feel through code that is less likely to explode randomly 🙂

But to make this blog not totally useless, I want to add that the new snapshot added to Portage does not only have all my changes above (that are pretty much useless at runtime, unless GCC really liked them, doubtful), but also features a new musepack useflag. Why, you’ll ask, as xine-lib was already able to play MusePack files… well the reason is simple: xine-lib up to now used an internal copy of libmusepack to play them, now I’ve added a switch to configure to disable musepack entirely, and one to use the external libmpcdec library rather than the old internal libmusepack copy… I’m not really sure what the changes are in libmpcdec, but other than being Gentoo’s policy to use external libraries whenever possible, this would be the first step to add a new demuxer too, that would then be able to decode all kinds of musepack files as long as libmpcdec is able to read them, kinda like the libflac demuxer does.

Talking of that demuxer, I’m wondering if I should boost its priority, so that if it’s enabled it is preferred to the internal copy.. this way it would actually mean something, right now it’s just a waste of time.

Another change that happened in xine-lib ebuild with the previous snapshot bump, by the way, is that SyncFB plugin is now forcefully disabled in both 1.1.3 and 1.1.4 snapshot. This is because it requires a kernel module from Tunetux project, that died in 2001, and is unlikely to work on 2.6, that it’s not even in Portage; its building was taking up time, space, and code that wasn’t possibly be used by anyone, now it should be better.

My TODOs for xine-lib are now implementing server string setup for PulseAudio plugin (so that you can choose to play on a different server rather than relying on PULSE_SERVER environment variable), and support for seeking in WavPack; once that is done, I’ll be looking for 5.1 support that is so not working right now neither with ALSA nor with PulseAudio as far as I can see, try to play the HD 720p version of the Fantastic Four 2 movie trailer, you can find it on Dave’s Trailer Page (pretty much a good source for Apple’s Mpeg4 videos to test media players with).

Now just a little note about KDE 3.5.6 and aRTs… as the tarball was just the same as the previous version minus the version number changed in makefiles, there won’t be an arts-3.5.6 in the tree. All packages should be now updated to just depend on the older version. I’m not even sure if there was a difference between 3.5.4 and 3.5.5, we could have spared one build already. After all, it is dead code.