ss: Relax but enforce the character limit in HTInterval strings
The string parsing logic in HTInterval casts the string length to
a byte, which can result in a negative value (and subsequent
NegativeArraySize exception) if the string is actually > 127 bytes
in its encoded form.
A comment mentions that the string length is checked at the
constructor, but this is false! No check is done whatsoever.
The limit should be checked.
While at it, the current limit of 127 bytes is very small for
string values. File system paths for example can easily add up
to more than 127 characters. For this reason, use a short (2 bytes)
instead of one byte to store the string length, which allows for
strings up to 32,767 bytes.
Finally, specify UTF-8 encoding explicitely. This is what was
happening on most platforms already, but it's a better practice
to specify it, and it makes static analysis happy.
Also happens to fix:
Bug: 496864
Change-Id: Ia801782696a1574568d52c52775d475ed2dcf173
Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Reviewed-on: https://git.eclipse.org/r/76060
Reviewed-by: Hudson CI
This page took 0.028115 seconds and 5 git commands to generate.