Null-terminated Unicode strings in java.io on Windows
program.spe at home.pl
Mon Jan 21 23:35:59 PST 2008
Dnia 21-01-2008, Pn o godzinie 23:57 +0100, Roman Kennke pisze:
> 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 characters is not required to be zero terminated and that one should use GetStringLength to determine the length.
> > Roman Kennke wrote:
> > > So this is indeed a bug, right? Do you think it makes sense to go out and fix it?
> > I'd start here:
> > 4616318 Spec for JNI's GetStringChars() is incomplete
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4616318
> Hmm, I'm not talking about fixing the spec (I've read that bug report
> while searching for clarfication on the spec actually). When the spec
> doesn't tell _that_ the returned array is zero terminated, I think we
> should assume that it isn't (and it seems to be the trend that the spec
> should be clarfied by saying that an implementation isn't required to
> return a zero-terminated array, but this is only speculation). What I'm
> asking is, should we fix the java.io C code to deal with
> non-zero-terminated jchar arrays? Unfortunately, this probably means
> allocating additional buffers, because we really need zero terminated
> strings here (AFAICS).
If the specification gets fixed so that GSC result MUST be z-term,
your VM will cease being conformant
so it will be fixed and no additional buffers will be needed.
More information about the core-libs-dev