Code Quality

The recently released GLib 2.25.15 contains a new class for dealing with dates: gdatetime.c. With apologies to Pauli: That code is not right. It is not even wrong.

The code basically claims to handle date+time+timezone. Such code, in principle, makes a lot of sense in Glib. But even a cursory scan through the code reveals numerous grave problems:

  • It reimplements the date handling code from GDate. Badly and buggy: even fairly simple things as advancing one day does not work. Actually, advancing by zero days does not work either.
  • Code like g_date_time_difference and g_date_time_get_hour as well as the representation of time-of-day makes it clear that the code does not and will not handle timezones properly. The author does not understand things like daylight savings time and the fact that some days are not 24 hours long under that regime.
  • Code like g_date_time_printf makes it clear that the author does not understand UTF-8. Here is an outline:

    for (i = 0; i < utf8len; i++)
    {
    const char *tmp =
    g_utf8_offset_to_pointer (format, i);
    char c = g_utf8_get_char (tmp);
    [...]
    }

    That has got to be the worst way to traverse a UTF-8 string seen in the wild. And note how it mangles characters with code points outside the range of “char”.

  • There is no error handling and the API as-is will not allow it.
  • The code obviously was not tested well.

Why does code like that make it into GLib? The code was reviewed by Glib maintainer Matthias Clasen. I do not think he did a very good job. (He is busy asking for patches, but not busy applying patches. Certainly he avoids talking about substance. In any case, the code does not need patches, it needs to be taken out back.)


* * * * *

The bigger question is how you control code quality in a large project like GLib/GTK+. It is a simple question with a very complicated answer probably involving test suites and automated tools. I do not have anything to say about test suites here.

In the free software world the automated tools mostly come down to the compiler, sparse, and valgrind. (Let me know if I have missed anything substantial.)

  • “gcc -Wall” or some variant thereof. GLib and Gtk+ use this and use it reasonably well.
  • “Sparse”. There are signs that GLib/Gtk+ have not been run through sparse for a very long time. Gio, for example, appears to never have been tested.
  • “Valgrind”. Valgrind is probably being used on GLib/Gtk+ regularly, but each new release seems to be putting new roadblocks in the way of making effective use of Valgrind. In modern versions you cannot make Gtk+ release its objects, so Pango will not release its stuff and the font libraries in turn will not release its. Do not get me wrong: exit(2) if a very efficient way of releasing resources, but not being able to — optionally — release resources manually means that you do not know if your memory handling works right.

In short: Glib and Gtk+ are slowly moving away from automated code quality checks beyond the compiler.

I used to run GLib/Gtk+ through Sparse and Purify. Over time I got the message that bug reports based on that were not particular welcome.

Comments are closed.