Debarshi's den

Archive for the ‘GNU’ Category

About -Wextra and -Wcast-function-type

leave a comment »

About eight months ago, around the time when GCC 8.x started showing up on my computers, I started moving my code away from using -Wextra. This aligns nicely with the move to the Meson build system, which is nice; but went against the flow of Autotools’ AX_COMPILER_FLAGS, which isn’t ideal but is an acceptable trade-off.

But why?

GCC 8.x added a warning called -Wcast-function-type to the -Wextra umbrella. It warns when a function pointer is cast to an incompatible function. At a glance, this seems desirable, but it isn’t. It runs contrary to one of the widely used C idioms in GNOME. For example, it’s triggered by this text book use of g_list_copy_deep to copy a list of reference counted objects:

another_list = g_list_copy_deep (list, (GCopyFunc) g_object_ref, NULL);

Note that this is different from -Wincompatible-pointer-types, which would’ve triggered if the cast to GCopyFunc was missing:

another_list = g_list_copy_deep (list, g_object_ref, NULL);

It’s easy to imagine similar examples with uses of gtk_container_forall or gtk_container_foreach with gtk_widget_destroy, and so on.

The C standard (eg., see article 6.5.2.2 of the C11 standard) steps around the issue of passing more arguments to a function than it actually has parameters for by calling it undefined behaviour. However, the calling conventions of all the platforms supported by GLib are defined in a way to make this work.

So how do we disable -Wcast-function-type?

One option is to use a compiler directive with #pragma as suggested by AX_COMPILER_FLAGS. However, attempts to ignore it through a #pragma on older versions of GCC that didn’t have this specific warning will trigger -Wpragmas, and, ironically, using G_GNUC_CHECK_VERSION to conditionally disable it on newer compilers will trigger -Wexpansion-to-defined, again, because of -Wextra and the fact that the implementation of the macro has a #ifdef around __GNUC__. Regardless, for a warning that gets triggered by such a widely used programming construct, it would lead to a ton of boilerplate all over the codebase, instead of being a solitary exception tucked away in one corner of the project.

Therefore, my preference has been to append -Wno-cast-function-type and -Wno-error=cast-function-type to the list of compiler flags of modules using -Wextra. This avoids almost all of the above problems. One small wrinkle is that if a translation unit or file does trigger some other unrelated diagnostic, then an older compiler will also emit -Wunknown-warning for the presence of the unknown -Wno-cast-function-type flag. I find this acceptable because, in the first place, a file shouldn’t trigger any other diagnostic, especially on an older compiler, and if there does happen to be something, say a deprecation warning, then it’s likely something that needs to be fixed anyway.

Given that this can repeat with future versions of GCC, it seems wiser to avoid -Wextra and instead explicitly list out the desired compiler warnings. This isn’t hard to do because the GCC documentation clearly marks which warnings are turned on by -Wextra, -Wpedantic, etc..

Written by Debarshi Ray

1 April, 2019 at 13:05

Posted in C, GNOME, GNU

MALLOC_PERTURB_

with 4 comments

MALLOC_PERTURB_ is a useful thing. If you are developing on glibc-based systems, I encourage you to put this snippet in your ~/.bash_profile:

MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
export MALLOC_PERTURB_

I have been using it for the last six years on all my computers (3 laptops running every Fedora x86_64 build released since then), and while things haven’t exploded, it has helped uncover the odd bug every once in a while. One such occasion presented itself this week.

I was busy following Ondrej’s hint, debugging why Eye of GNOME was taking so long to open a file from ownCloud. Imagine my shock when it would just crash after showing the window. The same optimization was working just fine on the gnome-3-18 branch, while master was crashing even without any changes. How could that happen? Obviously, while it was failing for me, it was working fine for all those who run unstable GNOME versions via jhbuild, gnome-continous, Fedora rawhide, etc.. Otherwise we would have been debugging this crash, and not a performance issue.

I guess, most of them didn’t have MALLOC_PERTURB_.

Here is another such story.

In case you were wondering, there is already an update on its way to Fedora 24 address the crash.

Written by Debarshi Ray

9 April, 2016 at 02:28

Gnash and Epiphany

with 5 comments

Long story short, the proprietary Adobe Flash was blacklisted in the GNOME 3.x releases of Epiphany because it uses Gtk+ 2.x (or 1.x) while Epiphany uses Gtk+ 3.x. An unwanted side effect of this is that it also disables Gnash, depriving me of my daily dosage of Youtube, Rebecca Black and crappy, obscure Bollywood songs.

So I fixed it. It is probably not the most correct way to do it, but then it can be a bit tricky to define what is correct in cases like this. In any case, GNOME Bugzilla #647516 has the patch and some details. (Thanks to Company for all the nitty gritty details about this.)

Written by Debarshi Ray

12 April, 2011 at 03:32

Posted in Epiphany, Gnash, GNOME, GNU

Tagged with

“… update Adobe Flash Player …” — Wait, what?

with 4 comments

When I restarted Firefox after updating it on my Fedora 14 system, I was presented with this:

I never installed Adobe Flash Player on this system.

For what it is worth, I use Gnash and, barring the occasional resource leaks, it has been providing me with my daily dosage of Youtube.

Written by Debarshi Ray

11 March, 2011 at 13:04

Posted in Fedora, Firefox, Gnash, GNU, Mozilla