From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12182 invoked by alias); 13 Sep 2002 17:16:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12148 invoked from network); 13 Sep 2002 17:16:08 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 13 Sep 2002 17:16:08 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g8DH2U311236; Fri, 13 Sep 2002 12:02:30 -0500 To: Daniel Jacobowitz Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] Character set support References: <1020913003056.ZM15701@localhost.localdomain> <20020913004205.GB19479@nevyn.them.org> <20020913140312.GA10942@nevyn.them.org> From: Jim Blandy Date: Fri, 13 Sep 2002 10:16:00 -0000 In-Reply-To: <20020913140312.GA10942@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00248.txt.bz2 Daniel Jacobowitz writes: > I'm not suggesting reading wchar_t's from the target; that's not > terribly useful a thing to do. You _want_ the host wchar_t. It is > a host type capable of holding a wide character; the type changes > based on platform and on whether or not the platform actually has > wide character support. If you're suggesting using the host's wchar_t to hold characters after conversion from the target charset to the host charset, then I'm with you. If you're suggesting using the host's wchar_t to hold character values that have been read from the target, but not yet converted to the host's charset, then I really disagree. The target's wchar_t could be 32 bits, while the host's might be 16 bits. > There's not much you can do if it doesn't, is there? Print things in hex? When the target->host conversion fails, you can't just drop the character, but you still need some way to represent the pre-conversion value in GDB. > Rather than using iconv, which is meant for converting strings of > text, it seemed to me when I wrote the above comments that we should > be using mbrtowc/wctomb functions. However, unlike iconv, they > appear to operate based on the current locale rather than a > specified charset. I suppose they are unsuitable and we'll have to > figure out how to use iconv appropriately. Yes, exactly. If mbrtowc were parameterized with the charset, it would work pretty well.