BUG: gtk-text-attributes cstruct is incorrect

[stacksmith]

See gtk/gtk.text-tag.lisp - at the end, it is:

...
 (:invisible :uint)
  (:bg-full-height :uint)
  (:editable :uint))

while recent gtk documentation shows

  guint invisible : 1;
  guint bg_full_height : 1;
  guint editable : 1;
  guint no_fallback: 1;
  GdkRGBA *pg_bg_rgba;
  gint letter_spacing;
  gchar *font_features;
};

So there are 4 single-bit packed values, and 3 more are missing.

[Ferada]

Yeah I'm super angry with GTK using bitfields in public structs. Ideally those were supported in CFFI. If you really need it ... I suspect writing the wrapper in C is less work than supporting the correct sizes and alignment etc. in CFFI. But you might already have done that? :)

Btw. GTK also fails to properly support these in their XML output (that is, via the GObject introspection), so no, that can't be used either to compute the correct offsets (the required fields are there, they just don't set them at all). I'm actually kind of at a loss of how to reliably arrive at the same layout as the C compiler would.

[stacksmith]

I believe layout of packed bitfields is not defined by the standard. Compilers have flags that affect structure packing behavior, making the situation very unreliable. I always assumed bitfields are packed into ints conceptually, but that is guesswork; in this case other members follow, which makes the offsets impossible to derive reliably.
Although since the next member is a pointer, it should be aligned to the nearest 8 bytes in 64-bit systems, I suppose.
And of course, having a pointer-int-pointer combination wastes 4 bytes on 64-bit machines...

[stacksmith]

I hate the idea of writing an extra C wrapper - the last time I went that route I wound up writing so much C that I was wondering why not just write the whole application in C...
I am working on a simple utility library that simplifies foreign structure access... It's a bit of a mess right now, but I will be cleaning it up as I go....

[Ferada]

Right, but all wrappers still won't allow us to access bitfields (reliably), right?

[stacksmith]

I can't think of a compiler that does not align to nearest power-of-two for bytes and pack bitfields. I suppose we should dig through the spec, although just thinking about it give mes the willies. After a brief stint on X3J11, I never want to see C++ specs ever again.