Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

contrib/platform: some declarations use a different integer width than the C prototype

Đang mở
  • Có gì không ổn?
#1,747 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend, devtools

Hướng nghiên cứu

Start with the declarations named in CoreFoundation.java, Advapi32.java, LibCAPI.java, X11.java, Carbon.java, OleAuto.java, and User32.java, then compare each against the C prototypes listed in the issue. Check the existing Colormap, NativeLong, LibCAPI.size_t, and WinDef.WORD mappings as relevant. Done means the affected Java declarations use compatible native types, with overloads where needed to preserve callers; consider the stated compatibility tradeoff for PostMessage.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

A few declarations in contrib/platform pass or return an integer whose width differs from the C prototype. None of them is known to give a wrong result today, but the Java type doesn't say what the C side reads. CFEqual is the one I'd look at first: it is the only Boolean return in CoreFoundation that isn't mapped to byte.

// contrib/platform/src/com/sun/jna/platform/mac/CoreFoundation.java:1053, :973, :1019
boolean CFEqual(CFTypeRef cf1, CFTypeRef cf2);
byte CFBooleanGetValue(CFBooleanRef bool);
byte CFNumberGetValue(CFNumberRef number, CFIndex theType, ByReference valuePtr);

// CoreFoundation/CFBase.h:745, :124 (macOS SDK 26.1)
Boolean CFEqual(CFTypeRef cf1, CFTypeRef cf2);
typedef unsigned char           Boolean;

The rest are arguments, plus one return:

declaration Java C
Advapi32.RegQueryValueEx, all 5 overloads (Advapi32.java:965-979) int lpReserved LPDWORD lpReserved
LibCAPI.gethostname, sethostname, getdomainname, setdomainname (LibCAPI.java:121-126) int len size_t __len
X11.XAllocNamedColor (X11.java:748) int colormap Colormap (unsigned long)
X11.XCreateSimpleWindow (X11.java:760-762) int border, int background unsigned long
X11.XKeycodeToKeysym, XGetKeyboardMapping, XInsertModifiermapEntry, XDeleteModifiermapEntry (X11.java:2025, :2125, :2169, :2178) byte KeyCode on Linux; unsigned int under NeedWidePrototypes
Carbon.InstallEventHandler, GetEventParameter (Carbon.java:60, :70) int inNumTypes, int inBufferSize ItemCount, ByteCount (unsigned long)
OleAuto.LoadRegTypeLib (OleAuto.java:883) int wVerMajor, int wVerMinor WORD
User32.PostMessage (User32.java:836) returns void returns BOOL
What it can cause

Nothing I can show for normal values:

  • libffi widens an integer argument to the full register by its declared sign, so a non-negative int arrives correctly where C reads 64 bits.
  • RegQueryValueEx's reserved argument is always 0, which arrives as NULL.
  • Version numbers fit in a WORD.
  • CoreFoundationTest.testCFEqual passes. JNA reads a boolean return as a 32-bit int, and CFEqual defines only the low 8 bits, so a wrong true would depend on what the compiled CoreFoundation leaves in the upper bits. I haven't seen that happen.

There are two edge cases. A negative value arrives as a huge unsigned one. And on an Xlib built with wide prototypes (anything but Linux and the BSDs, e.g. XQuartz), a key code of 128 or more reaches the key-code functions sign-extended. PostMessage returning void only means a caller can't see a failed post.

Fix

Use the C types: Pointer for lpReserved, LibCAPI.size_t for the lengths, the existing Colormap or NativeLong for the X11 values, WinDef.WORD for the versions, and byte for CFEqual. Add overloads wherever you'd rather not break compiled callers. I understand if you'd rather leave some of them as they are, especially PostMessage. Happy to send a PR for whichever you'd like.

How this was found

By a research tool that compares each native declaration against the C declaration of the function it binds. Nothing was built or executed; every file quoted is in this repository at 5.19.1, and unchanged on master.

Ngôn ngữ chính
Java
Star
8.9k
Fork
1.7k
Merge trung bình
1 ngày 13 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của java-native-access/jna

Tất cả issue của java-native-access/jna

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.