Null-terminated Unicode strings in java.io on Windows

[Krzysztof Żelechowski]

Dnia 25-01-2008, Pt o godzinie 22:16 +0000, Mark Wielaard pisze:
> Hi Robert,
> 
> Robert Lougher <rob.lougher at ...> writes:
> > This is getting a bit hostile for no reason....  Thinking about
> > alignment gives an interesting solution.
> > 
> > 1) Strings are not null-terminated
> > 2) For most strings the alignment gives the VM room to terminate in
> > place when GetStringChars is called
> > 3) Copy strings that can't be terminated in place.
> 
> Note that Strings have a backing [j]char array which can be shared between
> different Strings, and often are when read in in one go and then split in
> different sub-String objects. All these Strings have a shared slice of this
> backing jchar array, so there isn't any place to terminate it because that place
> will overlap with another slice that can belong to another String.

That changes the picture dramatically.  
Indeed, taking a prefix of an unmodifiable string 
requires copying data, as of the C language.  
I should have thought of that earlier, 
particularly because I gave run into this problem 
when I tried to make the source code for gmake straight.
I suppose K&R (or whoever they inherited the concept after) 
chose to z-term strings 
because they found out that writing a 0 at the end 
takes less memory than keeping a separate pointer to the end.
(This is true for character data only, 
that is why strings are so special).

Sorry for wasting your time.
Chris