Name: bb33257 Date: 07/01/99


String.getBytes() will crash when used with certain char-to-byte
converters. The actual internal error is an ArrayIndexOutOfBoundsError,
although you get a generic "internal converter failure" error
coming out of getBytes().

The problem is that the architecture is wrong for certain code
pages. Code pages that derive from the EBCDIC_STATEFUL encoding
introduce extra control characters into the output stream to
specify boundaries between ranges of single-byte characters and
ranges of double-byte characters. The converters account for
this by returning 3 for maxBytesPerChar. The per-character maximum
is 3 because it may be a two-byte character and it may be preceded
by a shift-in or shift-out character to mark a double-byte boundary.

The problem is that this won't account for an _extra_ terminating
shift-out character that goes on the end of the string when it ends
in double-byte mode. getBytes() allocates a byte buffer that's
too small, causing an ArrayIndexOutOfBoundsException when the
converter puts on the terminating shift-out character.

We could account for this by increasing maxBytesPerChar to 4, but
this would be extremely wasteful. The right answer is for getString()
to allocate a byte buffer that's one or two bytes bigger then the
calculated result to take care of any terminating control codes
that may be added by the converter.

For EBCDIC_STATEFUL, this should actually only be a problem if you're
converting a single Unicode character into EBCDIC. In the real
world, this is a rare but possible condition, and we should be
bulletproof. Also, the current converter unit tests (which obviously
haven't been run in a very long time) do single-character conversions
all the time right now and trigger this bug repeatedly. The converter
tests won't pass without this change.

To reproduce this bug, run test/sun/io/Converter/TestConv on Cp930,
Cp935, or Cp939 (other converters may also fail).
right answer is for String.getBytes() to allocate a byte buffer
that's a couple of bytes bigger than
(Review ID: 85116)

======================================================================