Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#1,747 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
8.9k
Fork
1.7k
Merge medio
1g 13h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di java-native-access/jna

Tutte le issue di java-native-access/jna

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.