summaryrefslogtreecommitdiff
path: root/include/ScopedJavaUnicodeString.h
diff options
context:
space:
mode:
authorPete Gillin <peteg@google.com>2018-07-31 17:00:09 +0100
committerPete Gillin <peteg@google.com>2018-07-31 17:00:09 +0100
commit5fce4e99e7586a68a68c69bef5cd6828e312f773 (patch)
tree33013c7a55c277bf636361ee7476ae0ea7d893b1 /include/ScopedJavaUnicodeString.h
parent0992342779b5198355c3b540dbed22d9856518a2 (diff)
Remove a superfluous array copy from several String ctors.
All of the String constructors that take a Charset to decode bytes ultimately go through StringFactory.newStringFromBytes. For Charsets other than UTF-8, ISO-8859-1, and US-ASCII, this method does a System.arraycopy of the bytes it gets from Charset.decode. The comment claims that this is to trim the array, and to defend against the Charset keeping a reference to the buffer it returns and modifying it and so violating String's immutability. However, the byte array is then passed to newStringFromChars, a native method which itself takes a copy of the correct number of bytes from the array it's given (see ultimately, SetStringCountAndValueVisitorFromCharArray in //art/runtime/mirror/string-inl.h). Therefore, the previous copy is unnecessary. There is a test for exactly this case, libcore.java.lang.StringTest#testStringFromCharset_MaliciousCharset, which uses a charset that modifies the CharBuffer after it's been returned, and asserts that this doesn't change the String, and it passes with this change. Bug: 111178950 Test: `cts-tradefed run commandAndExit cts-dev -m CtsLibcoreTestCases` Change-Id: I7e18467da764d8f0fec1359a6abcbde9d6b45972
Diffstat (limited to 'include/ScopedJavaUnicodeString.h')
0 files changed, 0 insertions, 0 deletions