Tag Archives: GCC

Colourful GCC output

For a long time, I’ve used colorgcc as a way to highlight warnings and errors in GCC output. It’s worked wonderfully, but today Travis pointed out that GCC has grown an option to enable colourised output: -fdiagnostics-color. This will be available in GCC 4.9, but the patch seems to have been backported to Fedora 19 so that more people can join in the fun.

This means I can throw away colorgcc from my .jhbuildrc:

os.environ['CC'] = '/usr/bin/color-gcc'

and enable -fdiagnostics-color:

os.environ['CFLAGS'] += ' -fdiagnostics-color=auto'

Even better, adding the following snippet to configure.ac in a standard automake project will automatically enable colourised compiler output if the compiler (is GCC and) supports it:

AS_COMPILER_FLAG([-fdiagnostics-color=auto],
                 [AM_CFLAGS="$AM_CFLAGS -fdiagnostics-color=auto"])

(In actual fact, I used ERROR_CFLAGS for this in folks, to keep unrelated CFLAGS separated, but that’s an implementation detail of folks’ build system.)

Use of the pure attribute for GObject convenience getters

In my quest to make my code completely correct and beautiful, largely through the liberal application of obscure and anal-retentive attributes like __warn_unused_result__ and __malloc__, I've hit a problem. Is it safe and correct to use __pure__ with GObject convenience getter functions?

As far as the literature explains it, “pure” C functions (no relation to pure mathematical or functional functions) can access pointers and global memory, but must not write to them, and cannot use system resources. In return, gcc can apply extra optimisations to calls to pure functions, since it can assume the return value of a pure function (for a given set of arguments) will not change, no matter how many times the function is called, until memory is written or a non-pure function is called. This allows for elimination of redundant calls to pure functions (since they're known to not have any side-effects) or, conversely, for gcc to add in calls to a pure function in preference to storing the result in memory, if it thinks that will perform better. Furthermore, gcc can perform loop optimisations on loops which just use pure functions.

This is all good, and I think I've done a good job of regurgitating the gcc manual here, but it doesn't answer the question. There are loads of GObject-based libraries out there, and none of them (as far as I can tell) are using pure convenience getters. I must be missing something from the wisdom of the masses.

The only situation I can think of where using the __pure__ attribute on a convenience getter function could result in incorrect code is if the object in question is modified from a thread (2) other than the one (1) calling the getter. For example, thread 1's frobnicate() function calls my_object_get_property_foo() a couple of times in a function at the same time as thread 2 calls my_object_set_property_foo(). Normally, let's say, the first call to my_object_get_property_foo() would return the old value, and the second call would return the new value. If my_object_get_property_foo() was a pure function, though, the compiler could potentially optimise out the second call, and so thread 1 would never see the new value of the “foo” property.

There are fairly few places where this is the desired behaviour with or without use of __pure__, though. The frobnicate() function is likely to have locking in this situation, which would prevent the race condition as normal, while still allowing the compiler to optimise out some of the calls to the pure my_object_get_property_foo() function.

In summary, what I'm proposing is that people use the G_GNUC_PURE attribute on their GObject convenience getter functions as much as appropriate. From my tests adding the attribute to functions in libgdata, it doesn't make much of a difference in performance but does reduce the code size of applications which use libgdata. (These tests weren't particularly thorough, though; they were actually just done against one function, looking at the disassembly of a test program which called it.)

Just as an example, here's a pure convenience getter function I wrote earlier:

GList *gdata_entry_get_categories (GDataEntry *self) G_GNUC_PURE;

GList *
gdata_entry_get_categories (GDataEntry *self)
{
	g_return_val_if_fail (GDATA_IS_ENTRY (self), NULL);
	return self->priv->categories;
}

On another note, that return type should really be const GList*, but GLib's list functions aren't const-correct.

Unused results

Work on libgdata is progressing nicely, and I've started on porting evolution-data-server to the shiny new calendar and contacts services provided by libgdata. One idea I recently had was to use the G_GNUC_WARN_UNUSED_RESULT macro (gcc's warn_unused_result attribute) on functions which return allocated data, to warn users of the library if they're not using the data, and thus leaking memory.

After a little research, I've found no real uses of that gcc attribute in this manner, which is rather surprising. Perhaps people think the effort of adding the attribute to all applicable functions is not worth it, given that 90% of the time, users of their libraries will correctly use the result of functions (if not free them)?

Anybody got any insights into the matter? I'll probably go ahead and add the attributes anyway, since there are definitely a few functions in libgdata which return allocated data when the user probably isn't expecting it.

C conundrum (below)

I've got a problem with C.

I'm trying to do something like the following:

#define FOOBAR 5
some_function_which_takes_an_integer (FOOBAR);
...
some_function_which_takes_a_string ("String literal with FOOBAR concatenated: "FOOBAR);

Which I want to expand to:

some_function_which_takes_an_integer (5);
...
some_function_which_takes_a_string ("String literal with FOOBAR concatenated: 5");

Unfortunately, I can't, and I can't see a way to do it. I'm basically looking for a way to stringise a preprocessor token's value so that it can be concatenated with other string literals before the compiler is allowed to molest it.

I've been talking with a friend, and seeing as there's a # preprocessor operator which stringises token names, it would make sense that there would be one for token values, but he can't think of one, or any other way to do it apart from using sprintf.

One other way of doing it would be to have two different versions of each preprocessor token – one an integer, and one a string – but that's ugly.

Anybody got any ideas?
Continue reading