prototypeless function representation

[Maurizio Cimadamore]

On 31/07/2024 15:51, Stephen Buergler wrote:
> 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.

The fix you mention where someone replaces a function from `()` to 
`(void)` would also caused all existing compiled code to fail when 
calling the updated function (as the calling convention used by already 
compiled code is now invalid).

The library file itself says nothing as to whether the function is 
prototypeless or not - in fact it says nothing as to whether the 
function has 1, 2 or 12 arguments.

In an ideal world, signature information would be part of the shared 
library format - then the Linker could use this information as part of 
its decision process. But that's not the world we live in. The correct 
calling convention is selected at the caller based on some knowledge of 
the signature of the function that needs to be called. In C, it means 
"by reading a header file". In FFM/Linker, this means "the user has to 
provide a description of what the called function is - e.g. which types 
are involved, and whether the function contains any variadic arguments".

Jextract, alone, cannot help here, because it only sees one side of the 
equation: how the native function is declared. But it doesn't see how 
the function is called, so it doesn't know, before-hand, how many 
arguments you want to pass (this information is crucial to call a 
prototype-less function correctly) and of which type (this information 
is also crucial as some numeric C promotions might be required when 
passing sub-int values to prototype-less functions).

In understand that, in some cases, the `()` syntax used in a header 
might be a bug. But I'm mildly against making assumptions on what the 
"header really meant" because... that is just guessing. If the function 
really takes no arguments, its signature really ought to be fixed.

>
> 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.

This is not helpful I agree - seems to be coming somewhere deep in 
libclang. I wonder if it's related to the parsing of the 
compile_flags.txt itself...

Thanks
Maurizio
>
>
> 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
>     <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md*additional-clang-options__;Iw!!ACWV5N9M2RV99hQ!LKsa80eHdqMFa9G7ebQHjquG6ySddsHQ6wiyi7XBqYPvzpsjbLSOH9YnAMtfVclhLFzD3vscQ8CMgL3tB1SRTzijs44$>
>
>     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/03b40d31/attachment.htm>