As it turned out, a similar test case already exists. I constructed it the
way
that it would have failed without this patch.
I also contacted Lasse and we came to the conclusion that the way
ToAsciiVector
and ToUC16Vector are implemented is unsafe as the encoding checking is
currently
the responsibility of the caller. This is risky as we have seen in this CL,
and
further examples exist, such as Runtime_StringSplit. No idea comes to mind
how
to fix this though.
I will fix Runtime_StringSplit as soon as my other CL containing the more
thorough String::IsAsciiRepresentationUnderneath() is landed so I can use
that.
Nevertheless it is probably a good idea to find a good way to deal with
this or
at least agree on the status quo before I continue to try to deal with
externalized strings in slices. By the looks of it, I will have to change
all
the places where ToAsciiVector and ToUC16Vector is called anyways, to deal
with
the case that the encoding of the slice does not agree with the encoding of
the
underlying parent string.
http://codereview.chromium.org/7685005/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
