Dnia 21-01-2008, Pn o godzinie 23:57 +0100, Roman Kennke pisze:
> Hi,
>
> Am Montag, den 21.01.2008, 14:45 -0800 schrieb Tim Bell:
> > Alan Bateman wrote (about GetStringChars):
> >
> > > [...] is length+1 and zero terminated. There is a long-standing bug to
> > > clarify the JNI specification
Hi,
Am Montag, den 21.01.2008, 14:45 -0800 schrieb Tim Bell:
> Alan Bateman wrote (about GetStringChars):
>
> > [...] is length+1 and zero terminated. There is a long-standing bug to
> > clarify the JNI specification on this topic. I believe it should say that
> > the returned array of Unicode
Alan Bateman wrote (about GetStringChars):
[...] is length+1 and zero terminated. There is a long-standing bug to clarify
the JNI specification on this topic. I believe it should say that the returned
array of Unicode characters is not required to be zero terminated and that one
should use Ge
Hi Alan,
Am Montag, den 21.01.2008, 21:52 + schrieb Alan Bateman:
> Roman Kennke wrote:
> > Hi,
> >
> > I'm trying to understand a piece of code in java.io . Let me try to
> > explain:
> >
> > When you look into WinNTFileSystem.c in the method
> > getBooleanAttributes(), you see that the file
Roman Kennke wrote:
Hi,
I'm trying to understand a piece of code in java.io . Let me try to
explain:
When you look into WinNTFileSystem.c in the method
getBooleanAttributes(), you see that the file object is converted to a
WCHAR* using fileToNTPath(). In io_util.c, fileToNTPath(), the filename
Hi,
I'm trying to understand a piece of code in java.io . Let me try to
explain:
When you look into WinNTFileSystem.c in the method
getBooleanAttributes(), you see that the file object is converted to a
WCHAR* using fileToNTPath(). In io_util.c, fileToNTPath(), the filename
string is extracted fr
