Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,747 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
backend, devtools

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
8.9k
Forks
1.7k
Merge moyen
1 j 13 h
PR mergées (30 j)
1

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de java-native-access/jna

Toutes les issues de java-native-access/jna

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.