char maps to wchar_t automatically, including arrays, which I believe
is reflected here: https://jna.dev.java.net/#mapping.
granted, this means that reads from wchar_t are effectively truncated
when wchar_t is 4 bytes, but to date this has not posed a problem.
BTW, wchar_t is 4 bytes on 32-bit linux as well.
On Aug 6, 2008, at 1:29 PM, Rick Goldstein wrote:
Greetings,
We have an API with a number of calls of the form
int GetSomeString(wchar_t* buff, int buffsize)
The calling program allocates buff, of length buffsize, and the C call
fills the buffer (up to the limit).
I have written a JNA wrapper for this code that uses char[] for the
wchar_t* arguments, and that works very well in a 32-bit environment
where wchar_t is two-bytes, just like a Java char. But now, we are
porting the C API to 64-bit Linux, where the wchar_t is actually
4-bytes. In this enviroment, the mapping no longer works, since the
types are no longer the same size.
So, how can I do the mapping in a platform-independent way so that my
JNA-based wrapper will work properly in both the 32 and 64 bit
environments?
Incidentally, some other methods in our API have const wchar_t*
arguments. For these, I use java.lang.String in the wrapper API, and
use a custom TypeMapper to map Strings to JNA WString. This works
like a charm in 32 and 64 bit versions.
Thanks for any help you can provide.
Best,
Rick