Re: [PATCH] Fix PR libgcj/36252, OutOfMemoryError in String constructor.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "David" == David Daney <ddaney@avtrex.com> writes:

David> In String(byte[] input_bytes, int offset, int count, String
David> encoding) we were assuming that the zero return indicated that
David> the output buffer was too small, so we would double its length
David> and try again.

Bah.  This API has bit us several times :-(

I was hoping we could switch entirely to the nio stuff, but Bryce said
that this caused performance regressions.

David> My fix is to assume that the size of the largest atomic output
David> sequence for *all* encodings is bounded and if the output
David> buffer is larger than this bound, then there is a problem with
David> the input and we should quit trying rather than expanding the
David> size of the output buffer.

There is code in InputStreamReader that handles this case in a
different way.  I think both pieces of code should work the same way;
so could you look at that one and see (1) if it is susceptible to this
or some related problem (i.e., does it ensure that we make progress?)
and (2) which is better?

David> A bonus fix is to catch java.io.CharConversionException and
David> stop the conversion.  This keeps this checked exception from
David> escaping from the constructor which does not declare that that
David> it throws said exception.

It seems bad to throw this at all.  IMO we should either declare it
properly, and fix the fallout in the Java code, or not throw it at
all.

For the String constructor one question is what the JDK does here.
I vaguely remember some funny business, but no details.

Tom