more gcj 3.0 fun -- catch { try {...}...}, encodings

[Tom Tromey]

>>>>> "David" == David Brownell <david-b@pacbell.net> writes:

David> Basically the failure is that certain logic in the XML
David> parser(s) under test seems to be misbehaving, and it's related
David> to exception processing.

Can you distill this to a simple test case?
That would be most convenient for debugging.
It could be a compiler bug.

David>     - When I put System.err.println() calls in there to figure
David>     out what gives, their output lands in the bitbucket.

I'd say that you could try using gdb, except that gdb is particularly
broken for gcj-compiled code right now :-(.

David>     - parsing a largish document encoded in EUC-JP worked, but
David>     its 'iso-2022-jp' or 'shift_jis' forms seemed to go into an
David>     infinite loop.  Shorter documents in those encodings worked
David>     fine.

gdb ought to work well enough for Java to track down an infinite loop.

David>     - Bogus encoding names ("XYZ+999" and the like) were
David>       accepted by the InputStreamReader constructor, but
David>       later caused null pointer exceptions.  Haven't quite
David>       tracked it down; natIconv.cc is the suspect.

I can't reproduce this one.  I tried the appended program.
If you can send a simple program to reproduce it I can debug it when I
find a moment or two.

David> One thing that looks strange is that the hashtable for names in
David> gnu.gcj.convert.IOConvert is case-sensitive, while the encoding
David> names are by definition (IANA) insensitive, which might have
David> affected the "shift_jis" mode.

I agree that this is a bug.  I have a patch which I will check in
shortly.  Thanks.

Tom

import java.io.*;
class foo {
  public static void main(String[] args) {
    try
      {
	InputStreamReader isr = new InputStreamReader (System.in, "XYZ+999");
	System.out.println (isr.read ());
      }
    catch (Throwable _)
      {
	System.out.println ("no");
      }
  }
}