Null-terminated Unicode strings in java.io on Windows
program.spe at home.pl
Mon Jan 28 08:24:26 UTC 2008
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.
More information about the core-libs-dev