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

[David Brownell]

> 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.

My first attempts to produce a simple version didn't succeed.
Maybe tomorrow.  (I presume the other main option would be
a runtime/eh bug?)

 
> 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.

That one should be easier to track down; that was the sort of
looking-at I was planning.


> David> One thing that looks strange is that the hashtable for names in
> David> gnu.gcj.convert.IOConvert is case-sensitive, ...
> 
> I agree that this is a bug.  I have a patch which I will check in
> shortly.  Thanks.

Just trying to help get an even better GCJ ... :)

- Dave