prototypeless function representation

[Stephen Buergler]

I guess so but prototypeless functions seem to work fine with other tools
including when they are brought into C++ builds.
Also right now if someone does go back and fix the header files it will
result in large breaking changes to the generated jextract bindings.

Neat but this flag seems to cause other issues.
FATAL: Unexpected exception
org.openjdk.jextract.clang.Index$ParsingFailedException: Failed to parse
...\librclone.h: ASTReadError occurred
It's not a very helpful error message.


On Mon, Jul 15, 2024 at 5:19 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> I don't think jextract should paper over what seem like bugs in header
> files (even if common ones) ?
>
> I think a possible workaround for dealing with such libraries is to pass
> clang the `-x c++` flag. This can be done as described here:
>
>
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#additional-clang-options
>
> Cheers
> Maurizio
>
> On 15/07/2024 08:08, Stephen Buergler wrote:
> > Hello!
> > I think most of the time there is something like
> > extern void RcloneInitialize();
> > is put into a header file it's meant to declare a function with no
> > parameters.
> > jextract outputs variadic versions of the binding though because
> > that's not what that means. It means that the function declaration has
> > no prototype and has an unknown number of parameters.
> > extern void RcloneInitialize(void);
> > This defines a function with no parameters and is what is usually
> > intended and with this version the jextract bindings now reflect that
> > there are no parameters to pass in.
> >
> > Would it make sense to change jextract to be able to treat these as
> > functions that take no parameters?
> > Alternatively, would it make sense to provide bindings for both
> > versions of the function?
> > If a `public static void RcloneInitialize()` and the variadic version
> > existed I think that would make sense.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20240731/73b5c743/attachment-0001.htm>