Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1280400 > unrolled thread

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

Started bySimon McVittie <smcv@debian.org>
First post2026-02-01 13:40 +0100
Last post2026-02-01 13:40 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#1126737: libgtk-3-dev: Incorrect type definition for `state` fields in Gdk-3.0.gir Simon McVittie <smcv@debian.org> - 2026-02-01 13:40 +0100

#1280400 — Bug#1126737: libgtk-3-dev: Incorrect type definition for `state` fields in Gdk-3.0.gir

FromSimon McVittie <smcv@debian.org>
Date2026-02-01 13:40 +0100
SubjectBug#1126737: libgtk-3-dev: Incorrect type definition for `state` fields in Gdk-3.0.gir
Message-ID<MjEU9-eWDL-3@gated-at.bofh.it>
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

[toc] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web