static inline and jextract
Manuel Bleichenbacher
manuel.bleichenbacher at gmail.com
Mon Sep 5 15:32:37 UTC 2022
Talking of things to skip:
Windows constants like "GUID_DEVINTERFACE_USB_DEVICE" should also be
skipped. Through two layers of macros, it resolves to:
extern "C" const GUID __declspec(selectany) GUID_DEVINTERFACE_USB_DEVICE
= { 0xA5DCBF10L, 0x6530, 0x11D2, { 0x90, 0x1F, 0x00, 0xC0, 0x4F,
0xB9, 0x51, 0xED } };
Can you spot the problem? It's a definition, and not a declaration. So
there can't possibly be a symbol for it in an external library.
At the moment, jextract will generate code, which then fails with
"unresolved symbol: GUID_DEVINTERFACE_USB_DEVICE". It clearly should be
skipped.
To reproduce it:
windows_headers.h:
#include <windows.h>
#include <initguid.h>
#include <usbiodef.h>
set SDK_DIR=C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0
jextract --source ^
-D _AMD64_ -D _M_AMD64=100 -D UNICODE -D _UNICODE ^
-I "%SDK_DIR%\um" ^
-I "%SDK_DIR%\shared" ^
--include-var GUID_DEVINTERFACE_USB_DEVICE ^
windows_headers.h
BTW: "static inline" is a somewhat newer addition to C but it's plain C,
isn't?
On Mon, Sep 5, 2022 at 5:10 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:
>
> On 05/09/2022 12:30, Manuel Bleichenbacher wrote:
> > Is there a reason to treat inline static functions different from
> > function-like macros?
>
> IMHO they should be treated similarly - e.g. they should be skipped.
>
> Also, I thought jextract skipped stuff that was not plain C, so I'm
> surprised to see symbols being generated for "inline" functions. Maybe
> we're missing some checks?
>
> Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20220905/271fcdea/attachment-0001.htm>
More information about the jextract-dev
mailing list