Automatic string conversion always appends a NUL terminator to native
strings (or at least it should). Is your library perhaps expecting a
double terminator? Where exactly did you need to add the explicit NUL?
On Jul 12, 2007, at 11:16 AM, Bartko Zoltan wrote:
In the meantime I found out that adding \u0000 to the end of the
string solves
the problem - I hope no memory leak is introduced with this.
I will have a look at the thing you said.
Thanks for the help.
Zoltan
Dňa Thursday 12 July 2007 17:04:21 Timothy Wall ste napísal:
On Jul 12, 2007, at 9:08 AM, Bartko Zoltan wrote:
Another thing I have found out:
if I do not use accented characters, the library receives the
strings
correctly. However, if I use accented characters, weird things
happen:
If you look at how native strings are generated (in
dispatch.c:newCString), there is likely a difference between the
actual encoding and the encoding you want.
The native code uses String.getBytes to generate a C char array; this
returns the bytes in the platform's native character set, not UTF-8.
This code should probably be refactored to move some of the
conversion into the java library and make the conversion dependent on
some external setting (either a system property or an option set on
the library).
With the current library you can always do String.getBytes(String
encoding) and pass in an array of bytes (don't forget to NUL-
terminate) instead of a String.
10 messages in net.java.dev.jna.usersRe: [jna-users] String related questions
.java, .java
