Bug(s) in java.lang.String

[Stephen Crawley]

I've found a bug in the Classpath java.lang.String implementation that
shows up on Kissme.  It happens in the Mauve test-case:

  gnu.testlet.java.lang.String.CASE_INSENSITIVE_ORDER

When the testcase calls:

  String.CASE_INSENSITIVE_ORDER.compare("\u00df", "sS");

the Kissme VM goes into an infinite loop.  The problem is in the private
"upperCaseIndex" method that performs a binary search of a table encoded
as a char array represented by the String value CharData.UPPER_SPECIAL.
The problem is that this method is accessing the table via the String's
value attribute, but it is not taking account of the String's 'offset'.
In Kissme, this String's 'value' is part of a larger char array and
the 'offset' is non-zero. 

One possible fix in this case is for upperCaseIndex to calculate the 
start and end bounds of the table as follows:

      int low = CharData.UPPER_SPECIAL.offset;
      int hi = low + CharData.UPPER_SPECIAL.count - 2;

instead of:

      int low = 0;
      int hi = upperSpecial.length - 2;

[Alternatively, it might be preferable to make the bounds static final 
constants.]

I suspect that other methods of String, etc that make use of CharData 
could be making the same mistake. 

-- Steve