From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20424 invoked by alias); 15 Jul 2009 19:50:50 -0000 Received: (qmail 20410 invoked by uid 22791); 15 Jul 2009 19:50:49 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from web33802.mail.mud.yahoo.com (HELO web33802.mail.mud.yahoo.com) (209.191.69.165) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 15 Jul 2009 19:50:43 +0000 Received: (qmail 45936 invoked by uid 60001); 15 Jul 2009 19:50:41 -0000 Message-ID: <466695.44735.qm@web33802.mail.mud.yahoo.com> Received: from [128.222.37.56] by web33802.mail.mud.yahoo.com via HTTP; Wed, 15 Jul 2009 12:50:41 PDT X-RocketYMMF: andywang621 Date: Thu, 16 Jul 2009 02:29:00 -0000 From: Andrew Reply-To: ke@alum.bu.edu Subject: Re: iconv returning byte order marks for Solaris 2.9 To: gdb-patches@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00401.txt.bz2 In the system I'm working iconv_open doesn't accept "wchar_t" as encoding n= ame. It failed when INTERMEDIATE_ENCODING was set to that.=20 But setting INTERMEDIATE_ENCODING to "UCS-4BE" eliminated the BOM in the be= ginning.=20 Andrew --- On Wed, 7/15/09, Tom Tromey wrote: > From: Tom Tromey > Subject: Re: iconv returning byte order marks for Solaris 2.9 > To: ke@alum.bu.edu > Cc: gdb-patches@sourceware.org > Date: Wednesday, July 15, 2009, 2:24 PM > >>>>> "Andrew" =3D=3D > Andrew=A0 > writes: >=20 > Andrew> I found a problem printing strings for gdb 6.8 > weekly snapshot=20 > Andrew> (2009 07 07) on Solaris 2.9.=20 >=20 > Thanks for finding and diagnosing this. >=20 > Andrew> I eventually found that changing > INTERMEDIATE_ENCODING=20 > Andrew> in gdb_wchar.h to "UCS-4" and applying the > following > Andrew> patch worked. Any comments? >=20 > Andrew> I'm not sure how to handle the > INTERMEDIATE_ENCODING=20 > Andrew> change, since it's probably system dependent.=20 >=20 > I don't have access to Solaris.=A0 If I understand > correctly, the > situation is: >=20 > * wchar_t on Solaris is encoded using UCS-4 > * iconv_open accepts "wchar_t" as an encoding name > * in this case, iconv emits a BOM >=20 > First, this seems like it must be a Solaris bug, just > because I can't > imagine how this would be useful. >=20 > I don't think we can use your patch as-is.=A0 It does > the BOM elimination > unconditionally, but really I think we can only do it on > platforms where > we know that wchar_t is UCS-4 (or UCS-2 I suppose). >=20 > Does Solaris 9 support a full suite of conversions?=A0 > If not, one option > would be to use libiconv, and find a way to disable most of > this code by > default on Solaris. >=20 > Failing that, the simplest fix would be if there is an > encoding > (compatible with wchar_t) we can use on Solaris which does > not insert > the BOM.=A0 For example, maybe "UCS-4BE" or "UCS-4LE", > depending on the > architecture.=A0 I think a fix like this could be done > entirely in > gdb_wchar.h.=A0 Could you try that? >=20 > As far as the host dependency, we can probably just check > __STDC_ISO_10646__. >=20 > Tom >=20