contrib/platform: some declarations use a different integer width than the C prototype
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Java
- スター
- 8.9k
- フォーク
- 1.7k
- 平均マージ
- 1日 13時間
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
java-native-access/jna のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 79/100
java-native-access/jna#1746 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
java-native-access/jna#1745 ·
-
`Native.typeOptions` never releases library interfaces, leaking classloaders対応中かも @curforever が 10 日前に担当しました。 オープン
難易度 4/5 1〜2日 初心者へのやさしさ 48/100
java-native-access/jna#1742 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 66/100
java-native-access/jna#1738 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
java-native-access/jna#1736 ·
java-native-access/jna の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
ome/ome-codecs#48 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
tonihele/OpenKeeper#672 ·
メンテナーはふだん 4 日以内に返信
-
Shaded google-api-client trust stores still include AAA Certificate Services (eMudhra CA compromise)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
snowflakedb/snowflake-jdbc#2763 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
ControlSystemStudio/phoebus#3983 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
zamojski/TowerCollector#292 · コメント 1 件 ·