Several GTK/GDK entry points are loaded at run time and called through a function-pointer type the stub declares itself. The cast tells the compiler what the signature is, so nothing is left to check against GTK's header — and five of them disagree with it.
Three read a return value from a function GTK declares void:
/* bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/gtk4.c:1127 — gtk_color_dialog_set_title */
rc = (jlong)((jlong (CALLING_CONVENTION*)(jlong, char *))fp)(arg0, (char *)lparg1);
/* gtk/gtkcolordialog.h */ void gtk_color_dialog_set_title (GtkColorDialog *self, const char *title);
/* gtk/gtkfontdialog.h */ void gtk_font_dialog_set_modal (GtkFontDialog *self, gboolean modal);
/* gtk/gtkfontdialog.h */ void gtk_font_dialog_set_title (GtkFontDialog *self, const char *title);
Same shape at gtk4.c:1887 (gtk_font_dialog_set_modal) and gtk4.c:1909 (gtk_font_dialog_set_title).
Two more disagree about the parameters:
/* bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/os.c:2494 */
rc = (jlong)((jlong (CALLING_CONVENTION*)(jint, jint))fp)(arg0, arg1);
/* gdk/gdktoplevellayout.h */ GdkToplevelLayout *gdk_toplevel_layout_new (void);
/* os.c:2514 */
rc = (jboolean)((jboolean (CALLING_CONVENTION*)(GdkToplevel *, jint, jint, GdkToplevelLayout *))fp)((GdkToplevel *)arg0, arg1, arg2, (GdkToplevelLayout *)arg3);
/* gdk/gdktoplevel.h */ void gdk_toplevel_present (GdkToplevel *toplevel, GdkToplevelLayout *layout);
What it can cause
ColorDialog.java:143 and FontDialog.java:171-172 call the first three, so that path runs. Java discards the value, so nothing goes wrong today — but reading the return of a void function is undefined behaviour, and it stops being harmless the moment anything uses rc.
For the other two I could find only the native declarations in GDK.java and no caller, so I believe they are unreachable — please treat that as my reading rather than a claim. If gdk_toplevel_present were called, GDK would take its second argument, a jint here, and use it as a GdkToplevelLayout *.
No observed failure; nothing was built or run.
Fix
gtk_color_dialog_set_modal, the fourth member of the same family, is already right:
// GTK4.java:460
public static final native void gtk_color_dialog_set_modal(long self, boolean modal);
/* gtk4.c:1106 */ ((void (CALLING_CONVENTION*)(jlong, gboolean))fp)(arg0, (gboolean)arg1);
So the other three want the same change: long → void in GTK4.java at :426, :432 and :444, then regenerate. Both call sites already ignore the result.
The two GDK declarations need the arguments GDK actually takes:
// GDK.java:1139 and :1199, as they would read after the change
public static final native void gdk_toplevel_present(long toplevel, long layout);
public static final native long gdk_toplevel_layout_new();
How this was found
By a research tool that compares each Java native declaration against the C declaration of the function its generated stub actually calls — here the case where the stub declares that signature itself, so no compiler sees both ends. Every line above was re-read on master (3e3b24b4) and against the GTK 4.23.2 headers.
Edited 2026-08-21: shortened. The claim, the evidence and the line numbers are unchanged.
Several GTK/GDK entry points are loaded at run time and called through a function-pointer type the stub declares itself. The cast tells the compiler what the signature is, so nothing is left to check against GTK's header — and five of them disagree with it.
Three read a return value from a function GTK declares
void:Same shape at
gtk4.c:1887(gtk_font_dialog_set_modal) andgtk4.c:1909(gtk_font_dialog_set_title).Two more disagree about the parameters:
What it can cause
ColorDialog.java:143andFontDialog.java:171-172call the first three, so that path runs. Java discards the value, so nothing goes wrong today — but reading the return of avoidfunction is undefined behaviour, and it stops being harmless the moment anything usesrc.For the other two I could find only the
nativedeclarations inGDK.javaand no caller, so I believe they are unreachable — please treat that as my reading rather than a claim. Ifgdk_toplevel_presentwere called, GDK would take its second argument, ajinthere, and use it as aGdkToplevelLayout *.No observed failure; nothing was built or run.
Fix
gtk_color_dialog_set_modal, the fourth member of the same family, is already right:So the other three want the same change:
long→voidinGTK4.javaat:426,:432and:444, then regenerate. Both call sites already ignore the result.The two GDK declarations need the arguments GDK actually takes:
How this was found
By a research tool that compares each Java
nativedeclaration against the C declaration of the function its generated stub actually calls — here the case where the stub declares that signature itself, so no compiler sees both ends. Every line above was re-read onmaster(3e3b24b4) and against the GTK 4.23.2 headers.Edited 2026-08-21: shortened. The claim, the evidence and the line numbers are unchanged.