[Pkg-pascal-devel] Bug#1126737: libgtk-3-dev: Incorrect type definition for `state` fields in Gdk-3.0.gir

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 01 Feb 2026 at 01:40:02 +0100, Mazen Neifer wrote:
>Building GTK bindings for Free Pascal using `git2pas` tool.

Do you mean gir2pascal, or something different? A tool of that name 
doesn't seem to be packaged as a binary in Debian, although 
lazarus-src-4.4 and similar packages seem to contain source code for it.

>Cheked the definition of the fields in GIR file and compared it with relevant C
>header files.
...
>There is clearly a mismatch between C and GIR files.

What do you believe to be a clear mismatch between the C and the GIR 
files? When reporting a bug it's usually best to describe what the 
problem is, rather than expecting a reader to guess it from a proposed 
solution.

>Provided a patch to fix the issue.

The GIR XML is machine-generated from the C source, C header files and 
shared library by tools in the gobject-introspection package, which are 
the reference implementation of GObject-Introspection - so patching the 
GIR XML by hand is not going to be the right solution to any problem.

>              line="703">a bit-mask representing the state of
>   the modifier keys (e.g. Control, Shift and Alt) and the pointer
>   buttons. See #GdkModifierType.</doc>
>-        <type name="ModifierType"/>
>+        <type name="ModifierType" c:type="GdkModifierType*"/>
>       </field>
>       <field name="button" writable="1">
>         <doc xml:space="preserve"

If the gobject-introspection tools generate GIR XML that gir2pascal 
can't cope with, then there are three possibilities:

1. C source, etc. mis-parsed by gobject-introspection;
2. wrong annotations (doc-comments) in GTK source that would have made
    gobject-introspection generate the right thing if corrected;
3. gir2pascal is misinterpreting the GIR XML

Other introspected languages seem to work well, so it seems most likely 
that you're encountering some sort of gir2pascal problem.

For the part of your patch quoted above, I believe it's referring to the 
GIR XML describing the GtkEventButton struct:

<record name="EventButton" c:type="GdkEventButton">
   ... more fields ...
   <field name="state" writable="1">
     <type name="ModifierType"/>
   </field>
   ... more fields ...
</record>

This seems like something that gir2pascal might reasonably be expected 
to be able to cope with: although the c:type of this field is not 
explicitly given in the GIR XML, gir2pascal should be able to infer that 
it's the same bit-representation as the <bitfield name="ModifierType"> 
that appears elsewhere in the file.

Adding `c:type="GdkModifierType*"` is certainly wrong: the field is a 
GdkModifierType (an integer, in practice 32 bits, containing flags), but 
you seem to be saying that you believe it should be a pointer to a 
GdkModifierType (in practice usually 64 bits). That isn't even the same 
memory layout...

In fact the field is declared as `guint` rather than `GdkModifierType` 
in the C source, but the doc-comment overrides it to be treated as 
GdkModifierType by introspection (something that was done intentionally 
by the GTK maintainers), and the whole GLib, GObject, 
GObject-Introspection ecosystem has an architectural assumption that 
enums are the same size as `int` and `unsigned int`.

     smcv