Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Five dynamically-loaded GTK/GDK functions are called through a wrong function-pointer type

未关闭
#3,533 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
c, java
领域
backend, desktop

调研方向

Start with the declarations at GTK4.java:426, :432, and :444 and GDK.java:1139 and :1199, then compare them with the generated stubs in gtk4.c and os.c at the cited lines. The issue says to correct the Java native signatures to match GTK/GDK and regenerate; verify the generated signatures and run relevant SWT tests or build checks. Done when all five declarations and generated calls match the cited GTK/GDK headers.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Java
星标
202
派生
206
平均合并
1 天 14 小时
30 天内合并 PR
117

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

eclipse-platform/eclipse.platform.swt 的其他 Issue

查看 eclipse-platform/eclipse.platform.swt 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。