typedef capablities within jnaerator

[rit001]

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]

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

[ochafik]

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]

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
[email protected]
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]

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]

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