JNAerator takes the following when running the jnlp (or the jar directly)
void __stdcall hello();
typedef void ( __stdcall *func)(int);
__stdcall void hello()
The interface func should probably extend StdCallLibrary.StdCallCallback and the library itself should extend StdCallLibrary.
MSDN says this (in practice, the compiler seems to lenient with respect to the order of the return type and the extension so my hope is jnaerator would be as lenient or at least take the standard syntax):
The impact would probably mean some really odd behavior when the stack is unwound when the callback is utilized or when the direct call is performed.
Reversing the order of the function prototype, __stdcall void hello() seems to extends the StdCallLibrary, but reversing it in the typedef does not help.
JNAerator: fixed handling of __stdcall function pointers and function…
…s (issue #282)
Hi @johnny-tc ,
Thanks for your report !
This is now fixed in the latest snapshot.
Thanks, it works for me now on the JNAerator runtime (based on JNA); when I use the BridJ runtime, which seems to be the default moving forward?, I get the following errors for the following input:
int __stdcall foo();
JNAerator: fixed generation of BridJ calling conventions (issue #282)