typedef capablities within jnaerator #273

Closed
rit001 opened this Issue Feb 24, 2012 · 5 comments

Projects

None yet

2 participants

@rit001
rit001 commented Feb 24, 2012

If I process the following C .h file (with supporting lib) using the latest jnaerator-0.9.10-SNAPSHOT-20120222.jar


typedef struct {
char *serverName;
} VixDiskLibConnectParams;

struct VixDiskLibConnectParam;

typedef struct VixDiskLibConnectParam *VixDiskLibConnection;

long VixDiskLib_Connect(const VixDiskLibConnectParams *connectParams, VixDiskLibConnection *connection);


I end up with the following definition within Java


public static native long VixDiskLib_Connect(Pointer<VixDiskLibConnectParams > connectParams, Pointer<Pointer<VixDiskLibLibrary.VixDiskLibConnectParam > > connection);

What has happened is that the type *VixDiskLibConnection has not be carried over by jnaerator. Is this to be expected?

Thanks (yet again)

Roger

@rit001
rit001 commented Feb 25, 2012

I've just extend my test/example so I am now wrapping the following


typedef struct {
char *serverName;
uint32 port;
} VixDiskLibConnectParams;

struct VixDiskLibConnectParam;
typedef struct VixDiskLibConnectParam *VixDiskLibConnection;

long VixDiskLib_Connect(const VixDiskLibConnectParams *connectParams, VixDiskLibConnection *connection);

long VixDiskLib_Disconnect(VixDiskLibConnection connection);


The output end up as


public static native void VixDiskLib_Connect(Pointer<VixDiskLibConnectParams > connectParams, Pointer<Pointer<VixDiskLibLibrary.VixDiskLibConnectParam > > connection);
public static native void VixDiskLib_Disconnect(VixDiskLibLibrary.VixDiskLibConnection connection);

As you can see, VixDiskLibConnection is correctly used within the def of the second function (but not the first) also as part of the overall output VixDiskLibConnection gets defined as a class.

Roger

@rit001 rit001 closed this Feb 25, 2012
@rit001 rit001 reopened this Feb 25, 2012
@ochafik
Member
ochafik commented Feb 29, 2012

Hi @rit001,

Thanks for your report !

You've uncovered a conflict in JNAerator's ugly typedef vs. type conversion code, I'll try to fix that as soon as I get some calm evening :-)

Cheers

@rit001
rit001 commented Feb 29, 2012

Thanks for the reply and the effect you are putting in. I would love to
help more by my java/programming skills are not up to working with your
codebase or the process you are implementing. This leaves me with reporting
issues and hopefully as you will have now seen from my 2 outstanding posts
trying to get the reports as focussed as I can, even if it takes a few
days.
Roger

On 29 February 2012 at 22:51 Olivier Chafik
reply@reply.github.com
wrote:

Hi @rit001,

Thanks for your report !

You've uncovered a conflict in JNAerator's ugly typedef vs. type
conversion code, I'll try to fix that as soon as I get some calm evening
:-)

Cheers


Reply to this email directly or view it on GitHub:

#273 (comment)

@rit001
rit001 commented Apr 1, 2012

Hi, I've just come back to JNAerator having been doing other things. Do you think you will get a chance to look at this issue in the near term, or should I start to modify the .h files to work around the limitation?

Thanks

Roger

@ochafik
Member
ochafik commented Apr 14, 2012

Hi @rit001 ,

Thanks a lot for your patience !
I've (finally) cleaned up JNAerator's typedef resolution logic, which fixes this use-case (fix deployed in latest 0.9.10-SNAPSHOT).

Please let me know if you face any other issue.

Cheers

@ochafik ochafik closed this Apr 14, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment