Older blog entries for company (starting at number 126)

warning options

I’m a very vocal person when it comes to enabling warnings for compilation of C code. I’m also very vocal about using -Werror, but that’s a longer topic I won’t go into here. I guess I could give a talk about why it’s critically important for the quality of your code to use -Werror. No, I’m gonna talk about the warning flags I’m using in Swfdec.

An important thing to note about warnings is that they flag code that is perfectly valid. So enabling warnings restricts you. It complains even though you write perfectly valid C code. What it does however is help you avoid common errors and force you to write cleaner code. It’s especially good at making sure you write clean code from the start instead of “I’ll clean that up later” code.

This is the default list of compiler warnings that even a lot of build scripts enable automatically. You should always enable it, as new warnings are only added to it when they clearly show bad code.

This is another set of compiler warnings. Most of them are very useful, some of them aren’t. I prefer to enable it and disable the not-so-useful ones (see below), as I profit from new warnings being added automatically.

This warning complains when you initialize sturcts or arrays only partially. It’s usual glib coding style to do just that:

GValue val = { 0, };

So I’ve disabled the warning. It’s important to know that partially initialized values do indeed initialize the rest of the value to 0, so the other values are by no means undefined.

This warns about parameters in functions that aren’t used in the function body. As vfuncs in classes and signal callbacks often have parameters that you don’t use, I prefer to disable this warning. (Note to self: file a bug against gcc so static functions that are used by reference don’t get flagged?)

This is a mostly useless warning to avoid really old code (and associated bugs). It disallows function definitiona like

foo (x)
  int x;

If you’ve ever seen this, you should consider yourself seriously oldschool.

This is a matter of taste. This warning enforces that all declarations are at the top of a function and you don’t do stuff like

for (int i = 0; i

It also ensures portability to old-school compilers.

Warns if a non-static function is not declared previously. As non-static functions should always be exported in headers, the header will have the previous declaration. So this warning finds two important cases:

  • You forgot to make the function static even though it should be. This happened very often to me before using this warning.
  • You forgot to include the header that declares this function. This can cause very nasty side effects, when you change the function parameters but not the prototype. You won’t get a warning if you forget the declaring header.

-Wmissing-prototypes is a less-strict warning of the same type and included in Swfdec’s flags just because we can.

Warns if a declaration appears twice. This usually means you have either forgotten to put #ifdef MY_HEADER_H defines in your header or you moved functions to a different header and forgot to delete the old one.

Warns if functions that don’t ever return (such as exit) are not flagged as such. Use G_GNUC_NORETURN to indicate those functions. This warning is mostly useless, but for me it managed to detect when I screwed up my ifs so that all code paths ended at a g_assert_not_reached() statement.

A really really useful warning (that emits way too many warnings in gcc 3.x). It warns about code like this:

int x = 3;
/* lots of code */
if (foo) {
  int x = 5;
  /* lots more code */
  printf ("%d\n", x);

You might have wanted to print the x you declared first, not the second one. It’s one of the bugs you’ll have a very hard time finding. It’s a bit annoying that functions such as index or y0 are part of the C standard, but you learn to avoid them.

Warns about adding/subtracting from void pointers. This usually works the same like char pointers, but it enforces that you manually cast it. The more important thing is that it catches you when a pointer was a void pointer even though you didn’t intend it to, especially in macros. Stupid example:

MyExtendedGArray *array = some_value;
MyType *nth_element = array->data[n];

This is actually the reason why the g_array_index() takes the type of the array data.

This warning is useful for portable code. Some weird processors (read: ARM) need to have values aligned to the right addresses and just doing int i = *(int *) some_pointer; can cause this to fail. gcc will warn you about such code, but unfortunately only for the architecture you’re compiling to. But still, if you include this warning, all the Nokia people interested in your code will tell you about it and then you can fix it.

Important side note: You can avoid this warning if you know that the alignment is correct by casting to an intermediate void pointer, like int i = *(int *) (void *) some_pointer;

Another very important warning. Strings like "Hello World" are constant in C and must not be modified. This warning makes all these strings be treated like const char * instead of just char *. This helps a lot in avoiding stupid things, but can require quite a bit of constness cleanup in ones own code if it’s retrofit onto existing code. It’s well worth doing the work however.

Warns if a function declared as inline cannot be inlined. This warning should not ever triggered, because a function should never be declared as inline. Wether to inline or not is a decision of the compiler and not of some coder. So never use the inline attribute. Not even when you are writing boot sequences in an operating system.

Warns about stuff like printf (foo);. You should use printf ("%s", foo); instead, as the variable foo can contain format strings such as %s. The printf argument should always be a constant string.

Warns about usages of printf() and scanf() that can cause security issues. You absolutely do want this warning.

Warns if you a switch statement does not have case statements for every value in an enumeration. This warning is invaluable for enumerations that you intend to add values to later on, such as cairo_format_t, because adding the new value will cause warnings in all switch statements using it instead of using the default case - which (in my code at least) is often an assert_not_reached. You can avoid this warning by casting the enumeration to an int: switch ((int) value)

Warns whenever there’s no default case in a switch statement. I tend to forget these quite often. If you don’t need a default case, just do:


Wrns if you initialize a variable with itself, like MySomething *sth = MY_SOMETHING (sth); (instead of MySomething *sth = MY_SOMETHING (object);). This was one of my favorite errors before using this warning.

Warns if a specified include irectory does not exist. This usually means you need to improve your autotools-fu, because you seriously messed up.

Warn if an #undef appears for something that wasn’t ever defined. This not only detects typos, but is most useful for clean code: undefs are after the code, so I often forget deleting it when removing a macro.

Warns if a struct or array is used as a return value. Either return a pointer instead or preallocate the value to be filled and pass it to your function.

Warns if a function looks like it should take printf-style arguments but isn’t flagged with G_GNUC_PRINTF.

Detects if you have used extern inside a function. Workaround: Include the right header. Or use the extern before the function.

You should probably read the definitive guide to compiler warnings, maybe you’ll find more useful warnings that I’ve overlooked. You’ll likely have a lot of a-ha experiences while reading it.

If you now decided you want to use these warnings in your code, what’s the best way to do it? The best way I know is to grab David’s awesome m4 script and put it in your m4 scripts directory. After that just use AS_COMPILER_FLAGS like this in your configure.ac:

AS_COMPILER_FLAGS (WARNING_FLAGS, "-Wall -Wswitch-enum -Wswitch-default")

This will check each of the flags you put there and put all the ones that work into the WARNING_FLAGS variable and ignores the ones that don’t work. So it’ll work perfectly fine with older or non-gcc compilers. And if you ever get annoyed by a flag or want to add new ones. you just edit the list.

Syndicated 2008-12-22 15:13:11 from Swfblag

on loneliness

I had a major breakthrough. Actually two. The first one was that I managed to watch a video via RTMP using Swfdec (Yahoo music and BBC use that). That got me really excited so I went to our IRC channel to tell people. This was when I had the second major breakthrough.

I relaized at that moment that there was noone anywhere that wanted to share my happiness. Noone saying “congrats”, let alone asking “How did you do that?”. I realized I’m a lonely hacker these days.

This got me wondering why I’m still working on Swfdec, and the answer was that I don’t know. Originally it started because I wanted to watch Youtube with free software. I’m able to do this for almost 2 years now. Then it was exciting to figure out how Flash worked and how hard it’d be to write a Free player. I know pretty much everything I want to know about Flash today. The last year I’ve worked on Swfdec because other people were interested in it. But those people went away to do other things and these days I’m the only one left working on it. And as I mentioned above, that’s not fun.

So I’m going to change something. I’m not sure what it will be, but it’s equally likely that I continue working on Swfdec as it is that I’m gonna do something else entirely. We’ll see. If you know something You’d like me doing, mail me. :)

Syndicated 2008-12-18 11:05:28 from Swfblag

Dave, It’s dead simple. FFmpeg developers do not care about you - or anyone else. The only thing they care about is sitting in a cave admiring their awesomeness.

I’d suggest you go and file a bug with VXL and tell them that their ffmpeg handling is wrong (as they linked to and not forked it). While doing this, suggest to them that they might wanna use GStreamer (or Xine or whatever) instead, as those projects provide stable API and are actually more powerful.

In Swfdec I’ve seen the light and removed the ffmpeg option. They don’t care about me, so I won’t care about them.

Or to paraphrase: There’s always the ffmpeg solution to every multimedia problem — neat, plausible and wrong. Or did you pad and align your buffers?

Syndicated 2008-12-05 18:56:39 from Swfblag

thin layers

Apparently Aaron had to answer the Why isn’t Phonon useless? question yet again. I guess when something is known for abstractionitis, it deserve that.

What I’m going to rant here though is about abstractions, that claim to be “thin layers” over something else and that makes them “good” because they can switch “backends” easily and then are “more flexible”. In case you don’t know what I’m talking about, here’s some examples: Phonon, XUL, Cairo

The biggest problem abstractions have is the lowest common denominator problem. You need a fallback mechanism if one of your backends doesn’t implement your feature. Most of the time, this fallback mechanism is not implemented, so using it ends up either being a “query capability and only use it if available” dance in applications or it just does nothing and users on weird backends (like BSD ;)) wonder why your application doesn’t work.

And even if you have a fallback mechanism, it often is very suboptimal and behaves wrong when compared to “native” output. Firefox’s awesomebar dropdown still looks totally out of place in GNOME compared to Epiphany’s and sometimes selecting text in cairo-generated PDFs is impossible, because the text was rendered using an image fallback.

Another similar problem is that you have to limit the API you design to the backends. You cannot sensibly make use of a real cool feature if most of your backends don’t support it - or you have to implement it yourself for all the backends. Depending on your choice, you either end up with unhappy users or N times as much work.

In the same vein there’s the problem with additional API burdened upon the user to properly support all backends. Cairo is going to gain the useful feature to mark text as a link or attach the riginal JPEG data to an image, so the PDF and SVG backends can include this information. However, this information is completely useless if you output to the screen.

And finally you’re writing a lot of code - mostly compatibiltiy code matching your API with the backends or fallback mechanisms for their unimplemented features. So you have to ask yourself if the “thin layer” you’re writing is really that thin or if you’d better use the underlying features directly. From my experience the answer usually is to use the underlying feature directly unless the “thin layer” adds some substantial features itself.

Syndicated 2008-10-29 10:45:48 from Swfblag

good job

I just upgraded my machines to Intrepid, so I could fix Totem’s slow startup speed. And it turns out stuff works better than before. Thank you everybody - in particular Kernel, X and Ubuntu people - for making stuff work so well.

Syndicated 2008-10-06 21:45:38 from Swfblag


What’s scary about 5 second boot is not that it is possible. What is scary is that Ubuntu, Fedora, Debian, Mandriva, Gentoo and Suse couldn’t do it. Not even close.

And that seems to be a mindset issue: “It’s not about booting faster, it’s about booting in 5 seconds.”

Syndicated 2008-10-03 09:56:36 from Swfblag

scripting GNOME

So, lots of talk about sripting engines on Planet GNOME. I was first planning this as an answer to Alex’s GScript introduction, but I thought others might be interested, so here it goes:

Here’s the three things I’d care about in a GNOME scripting environment a lot:

The most important thing is of course the bindability. You need to make it incredibly simple to bind stuff to or from GObject stuff. It looks like GScript already does an awesome job at this with natively marshalling everything and so on.

Another important thing is this: Does GScript ship programming tools and provide a way to do RAD? I’m thinking console, debugger, dnd script installation etc here. Not just for people writing scripts (where I’d want completion and built-in documentation), but also for me when making my application scriptable and having to debug refcounting issues because a script holds on to a GObject that my C code thinks is gone already.

But the most important thing for scripting I think is security. I want to be able to download scripts from untrusted sources (read: the Internet) without fear of them doing anything bad to my computer or its data. This is doubly complicated if exposing stuff is too easy. So if you expose “RemoveSong” in Rhythmbox, you already have a problem.
The reason you want to allow this, is twofold: 1) We are incredibly bad at maintaining a useful set of plugins (or art - same issue for themes). That’s not due to lack of capability, but because it’s booooring. 2) If you would set up a website where everyone can upload/download/vote on scripts and even integrated that site into your application, you would make the application self-improve and lower the barrier of entry for new people incredibly.
Here’s a use example

  1. I want to remove red eyes in the GIMP. So I open the plugin browser, enter “red eye” and get a list of plugins (note that none of these plugins are installed). I select the highest-rated (or most-installed one) and it launches, asking me to select the red eyes and afterwards removes it.
  2. I decide I’m smart and can write code that detects the red eyes automatically, so I select the script, click on “edit” and modify the script. After half an hour (read: 2 weeks) it does what I want. I’m happy.
  3. When looking through my scripts, I see the “upload” button next to my red-eye removal tool. So I click it and it’s available for everyone else.
  4. Go to 1, replace “I” with “you” and “selecting the area” with “speed”, “accuracy” or whatever other feature.

This gets you the whole bazaar style software evolution without human intervention, automatically and for free. The only people I know that are doing something like this are Userscripts for Greasemonkey, but even that doesn’t look very professional.

Syndicated 2008-09-09 11:37:39 from Swfblag

Why Python will never be fast

Yesterday, when reading the Tracemonkey stuff, I realized this. The question “My code runs slow, how to make it go fast?” has two answers: “Improve the compiler/runtime to make it go fast.” and “Rewrite it in another language that can go fast.” As long as the second option is possible, there’s just no need to spend a huge amount of brain on the other option.

Besides, I’m back from my holidays where I’ve played with Flash 9 scripting in Swfdec. While it won’t make it for Swfdec 0.8, I’m positive 0.10 will play ABC-scripted Flash.

Syndicated 2008-08-24 12:45:20 from Swfblag


Yay, I’ll be on holidays on Madeira for the next 3 weeks. So if I don’t answer to email, now you know why. (I didn’t break the GNOME build on pourpose, I swear!)

To not leave you without code to break, I did releases of Swfdec: 0.6.8 (stable) and 0.7.4 (unstable) with corresponding swfdec-mozilla and swfdec-gnome releases.

Last but not least, I also uploaded the slides for the talk I gave at LugRadio Live and GUADEC. Of course it’s a Flash file. Navigate using space, left and right arrow. Mouse click (un)fullscreens. Flash is a pretty great presentation creation framework, especially because everybody can just watch the presentation in the browser the same way I did it.

Syndicated 2008-07-30 20:38:58 from Swfblag

If we’d do power management like that…

It’s sad when all we have to offer to sexually frustrated people is hate and social exclusion. I’ve started to wonder if the bad reputation of Open Source communities is more related to their unsympathetic behavior than to their photos.

Syndicated 2008-07-15 08:04:05 from Swfblag

117 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!