This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Another 646 patch and performance comparison with TOWER
- From: Tom Tromey <tromey at redhat dot com>
- To: martin dot kahlert at infineon dot com
- Cc: java-patches at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: 02 Apr 2002 13:56:49 -0700
- Subject: Re: Another 646 patch and performance comparison with TOWER
- References: <20020328125255.A23871@keksy.muc.infineon.com> <87bsd79l2g.fsf@creche.redhat.com> <20020402103506.A16798@keksy.muc.infineon.com>
- Reply-to: tromey at redhat dot com
>>>>> "Martin" == Martin Kahlert <martin.kahlert@infineon.com> writes:
Martin> Inside init (java/lang/natString.cc) we get into
Martin> BytesToUnicode::getDefaultDecode And after the system did not
Martin> succeed with any useful encoding, an
Martin> UnsupportedEncodingException is thrown which is handled by
Martin> substituting 646 by 8859_1 (see the code above these lines).
In gnu.gcj.convert.IOConverter I see this:
// On Solaris the default encoding, as returned by nl_langinfo(),
// is `646' (aka ASCII), but the Solaris iconv_open() doesn't
// understand that. We work around the problem by adding an
// explicit alias for Solaris users.
hash.put ("646", "ASCII");
Why doesn't the `646' get turned into `ASCII' in getDecoder?
>> Could you try this patch? Be sure, of course, to back out your
>> current patch before applying this one.
Martin> I tried it but the patch seems to be buggy:
Yeah. Let me work on it some more.
Tom