Null-terminated Unicode strings in java.io on Windows

[Krzysztof Żelechowski]

Dnia 25-01-2008, Pt o godzinie 13:14 +0000, Mark Wielaard pisze:
> Krzysztof Żelechowski <program.spe at ...> writes:
> > 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. 
> 
> Eh, that doesn't seem right at all.
> The specification currently doesn't guarantee that the result is a jchar array
> that is zero terminated. So you can expect current runtimes not to do this. As
> Roman said at least JamaicaVM doesn't do this. I just checked the
> implementations gcj and jamvm, they both also don't make any such guarantee
> (cacao does seem to add an extra 0 at the end of the result it returns though).
> So "clarifying the spec" would break a lot of code of currently conforming
> implementations. The code relying on this behavior seems to be just buggy and
> should be fixed imho.

The specification is buggy
in that it does not take into account the operating system interface 
and makes correct memory management inefficient 
for the benefit of sparing one byte per buffer 
where an OS call is not needed.
Ridiculous.
The developers at Sun 
found the correct way to interpreting the specification; 
the other ones followed it blindfolded.  It is now time to repent.

Cheers,
Chris