contrib/platform: some declarations use a different integer width than the C prototype
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
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
intarrives correctly where C reads 64 bits. RegQueryValueEx's reserved argument is always 0, which arrives asNULL.- Version numbers fit in a
WORD. CoreFoundationTest.testCFEqualpasses. JNA reads abooleanreturn as a 32-bit int, andCFEqualdefines only the low 8 bits, so a wrongtruewould 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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di java-native-access/jna
-
MacFileUtils: FSPathMakeRef passes an int where the C function takes its FSRef output pointerAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 79/100
java-native-access/jna#1746 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
java-native-access/jna#1745 ·
-
`Native.typeOptions` never releases library interfaces, leaking classloadersForse già presa @curforever l’ha presa 11 giorni fa. Aperta
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
java-native-access/jna#1742 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 66/100
java-native-access/jna#1738 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
java-native-access/jna#1736 ·
Tutte le issue di java-native-access/jna
Issue simili
-
dev/release: verify-release-candidate.sh runs 0 Java tests with Debian's MavenForse già presa @kou l’ha presa oggi. ApertaType: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/arrow-adbc#4947 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
lysine-dev/okhttp#9814 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
1.20.1-FORGE bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
MehVahdJukaar/WoodGood#1348 ·
-
documentation faq
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100