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

Mon Jun 25 21:25:00 GMT 2001

>>>>> "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");
 }
 }
}