Crusty Blaa

I spent some time floundering about a while ago trying to figure out a
Javascript hack to allow you to mark all mails in a mailman moderation
queue to be discarded. I certainly wasn't going to manually click
"Discard" for each of the 400 mails in the gconf-list queue.

DV saved me with some
jamesh magic.

Mailing list admins, bookmark this link -
Discard all mails%7Bel.checked=true;%7D%7D%7D)())

(No, don't click on the link. Right-click, "Bookmark link...")

I reckon a lot of hackers don't realise how wary they need to
be when using enums. Problems occur frequently because people
(usually unwittingly) make assumptions about either the size,
alignment or signedness of the integer representation for the
enum which the compiler uses.

C99 says Each enumerated type shall be compatible with
an integer type. The choice of type is implementation-defined.
An implementation may delay the choice of which integer type
until all enumeration constants have been seen. What
this means is that once the compiler has seen all the constants
you have defined for that enum, it will then decide what integer
representation to use and that could be a signed or unsigned
integer of any size.

So, GNOME hackers beware. gconf_enum_to_string() is
nasty. Have a look at the prototype:

gboolean  gconf_string_to_enum (GConfEnumStringPair  lookup_table[],
                                const gchar         *str,
                                gint                *enum_value_retloc);

{
  enum { A, B } test_enum;

  gconf_enum_to_string (enum_to_str_table, str, (int *) &test_enum);
}

This is guaranteed to cause crashes on some architectures since
alignment of the enum is different from the expected
alignment of an int. So it should be:

{
  enum { A, B } test_enum;
  int test_int;

  if (gconf_enum_to_string (enum_to_str_table, str, &test_int))
    {
      test_enum = test_int;
    }
}

Also, this breaks:

{

  enum { A, B } test_enum;

  int test_int;
test_enum = -1;

  gconf_enum_to_string (enum_to_str_table, str, &test_int);

  test_enum = test_int;
if (test_enum

The problem here is that you're assuming the enum has a signed

representation when in fact the compiler may choose an unsigned

representation. If the conversion fails, if (test_enum

will not detect it.

Alex also points out that when adding values to an enum in an API

you need to be careful that you're not unwittingly changing the

ABI because the compiler chooses to use a large integer representation

for the enum than was previously used.

I hate now knowing how things work. Especially things that I
rely on heavily as a hacker. But I love it when I get a chance
to finally figure out how the damn thing works and it turns out
to be beautifully simple.

This week I found that I had to debug a small part of libtool's
behaviour. It had always worked for me before and I had assumed
it worked a certain way, but in this case it just wasn't
working properly. I could feel myself breaking out in a cold
sweat. Don't make me debug libtool! Please God, noooo...

But the clouds parted. And it was simple.

When you build an executable, and it links against a library
in the same module, you need some way to be able to run that
uninstalled executable with the uninstalled library. So,
libtool puts a script where you think your uninstalled
executable should be and here's what it does

• When you run the script for the first time, it re-links
  your executable with --rpath $path-to-lib/.libs and
  places that executable in .libs/lt-myexec.
• That causes the linker to to put a DT_RPATH ELF
  attribute in the executable which tells the dynamic loader
  where to looks for libraries. (See the ld.so manpage)
• And finally, the script just runs the modified executable.

For example:

  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  $> ./gdk-pixbuf-csource
  Usage: gdk-pixbuf-csource [options] [image]
  $> ls -l .libs/*gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51262 Feb 26 11:28 .libs/gdk-pixbuf-csource
  -rwxrwxr-x    1 markmc   markmc      51294 Feb 28 15:48 .libs/lt-gdk-pixbuf-csource
  $> objdump -p .libs/gdk-pixbuf-csource | grep RPATH
  $> objdump -p .libs/lt-gdk-pixbuf-csource | grep RPATH
    RPATH       /gnome/head/cvs/gtk+/gdk-pixbuf/.libs:/gnome/head/INSTALL/lib
  $> ldd .libs/gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/INSTALL/lib/libgdk_pixbuf-2.0.so.0 (0x0087d000)
  $> ldd .libs/lt-gdk-pixbuf-csource | grep gdk_pixbuf
          libgdk_pixbuf-2.0.so.0 => /gnome/head/cvs/gtk+/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so.0 (0x004a0000)

Not exactly, earth shattering. But nice to know.

I've been really taken by surprise at how my motivation has jumped
hugely with the move to Red Hat. I'm even enjoying things like bugzilla
work, packaging and release-team stuff these days. Clearly, this can't
last. And I've got to get back hacking on things like Vino soon ...

GNOME 2.6 looks like its pretty much on track. Things like the gtk+
schedule and the constant string freeze breakage has given the release
team the heebie jeebies somewhat, but after our irc meeting last night
I'm feeling pretty confident the release will come out without any huge
hitches.

Alex and I have been updating the GNOME packages in Fedora Core to the
latest GNOME Beta ones. Hopefully, by the time FC2 test2 goes into devel
freeze on Friday we'll have most of the packages updated. A big priority
is to get the new file selector out to the Fedora testing masses, so
I'm going to update gtk+/atk/pango/glib to the latest today. Also going
to shove the little gnome-netstatus applet in too :-)

So, I had a discussion with the RFB protocol maintainers at
RealVNC about getting the
new RFB security types - which I added in Vino for doing the
encryption thing - registered in the protocol. As far as I can
make out at this point:

• There are more security types registered than appear in
  the protocol specification.
• Security types 1-16 are reserved for "standard" security
  types.
• A security type becomes "standard" when it is added to the
  "reference implementation" ... which just happens to be
  the same product RealVNC is trying to make money from.

I can't make up my mind whether I care about this or whether
I should just leave sleeping dogs lie. My main worry is what
happens if we decide there are other additions we want to make
to the protocol. Oh well, cross that bridge when we come to it.
The RealVNC guys are friendly, so I don't expect there would
actually be problems.

In the end, we agreed that I had to use different numbers to
identify the new security types and I had to modify the way
the new security type actually worked. End result - I've just
pushed a new version of Vino with incompatible changes in the
protocol.