jnaerator seems to generate invalid stubs for the callback / library under the following code: #282

Closed
johnny-tc opened this Issue Mar 8, 2012 · 2 comments

Projects

None yet

2 participants

@johnny-tc

Actual Behavior:
JNAerator takes the following when running the jnlp (or the jar directly)

void __stdcall hello();
typedef void ( __stdcall *func)(int);

and generates:

package test;
import com.ochafik.lang.jnaerator.runtime.LibraryExtractor;
import com.ochafik.lang.jnaerator.runtime.MangledFunctionMapper;
import com.ochafik.lang.jnaerator.runtime.Mangling;
import com.sun.jna.Callback;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
/**

  • JNA Wrapper for library test
  • This file was autogenerated by JNAerator,
  • a tool written by Olivier Chafik that uses a few opensource projects..
  • For help, please visit NativeLibs4Java , Rococoa, or JNA.
    /
    public interface TestLibrary extends Library {
    public static final String JNA_LIBRARY_NAME = LibraryExtractor.getLibraryPath("test", true, TestLibrary.class);
    public static final NativeLibrary JNA_NATIVE_LIB = NativeLibrary.getInstance(TestLibrary.JNA_LIBRARY_NAME, MangledFunctionMapper.DEFAULT_OPTIONS);
    public static final TestLibrary INSTANCE = (TestLibrary)Native.loadLibrary(TestLibrary.JNA_LIBRARY_NAME, TestLibrary.class, MangledFunctionMapper.DEFAULT_OPTIONS);
    public interface func extends Callback {
    void apply(int int1);
    };
    /
    *
    • Original signature : __stdcall void hello()
    • native declaration : line 2
      */
      @Mangling({"_Z5hellov", "?hello@@YAXXZ"})
      void hello();
      }
      }

Expected Behavior:
The interface func should probably extend StdCallLibrary.StdCallCallback and the library itself should extend StdCallLibrary.

Notes:
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):
http://msdn.microsoft.com/en-us/library/zxk0tw93%28v=vs.80%29.aspx

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.

@ochafik
Member
ochafik commented Mar 10, 2012

Hi @johnny-tc ,

Thanks for your report !

This is now fixed in the latest snapshot.

Cheers

@ochafik ochafik closed this Mar 10, 2012
@johnny-tc

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();


  1. ERROR in file:\test\TestLibrary.java (at line 20)
    @Convention<Convention.Style.StdCall >
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Syntax error on token(s), misplaced construct(s)

  2. ERROR in file:\test\TestLibrary.java (at line 20)
    @Convention<Convention.Style.StdCall >
    ^^^^^^^^^^^
    The annotation @Convention must define the attribute value

  3. ERROR in file:\test\TestLibrary.java (at line 20)
    @Convention<Convention.Style.StdCall >
    ^
    Syntax error on token ".", extends expected

    3 problems (3 errors)INPUTS = {file:///test/TestLibrary.java=file:///test/TestLibrary.java:
    package test;
    import org.bridj.BridJ;
    import org.bridj.CRuntime;
    import org.bridj.ann.Convention.Style;
    import org.bridj.ann.Convention;
    import org.bridj.ann.Library;
    import org.bridj.ann.Runtime;
    /**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment