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