From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8697 invoked by alias); 1 Feb 2009 23:16:14 -0000 Received: (qmail 8689 invoked by uid 22791); 1 Feb 2009 23:16:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 01 Feb 2009 23:16:08 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 34196109AE; Sun, 1 Feb 2009 23:16:06 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id DBA26108C4; Sun, 1 Feb 2009 23:16:05 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LTlXo-0006mH-Vd; Sun, 01 Feb 2009 18:16:04 -0500 Date: Sun, 01 Feb 2009 23:16:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: Joel Brobecker , Julian Brown , gdb-patches@sourceware.org Subject: Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support Message-ID: <20090201231604.GA24974@caradoc.them.org> Mail-Followup-To: Tom Tromey , Joel Brobecker , Julian Brown , gdb-patches@sourceware.org References: <20090115202411.5f154657@rex.config> <20090130194343.GA3964@adacore.com> <20090201182344.GD4597@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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-02/txt/msg00016.txt.bz2 On Sun, Feb 01, 2009 at 03:40:29PM -0700, Tom Tromey wrote: > Daniel> It seems like a dummy version of iconv_open which only succeeds if the > Daniel> two character sets are the same, plus a pass-through version of iconv, > Daniel> would be enough to remove the iconv dependency. That degraded mode > Daniel> covers all local debugging. > > The wchar_t issue comes into play because we actually do two > conversions when printing: one from the target charset to the host > wchar_t, and then a second one from the host wchar_t to the host > "narrow" charset. > > This just adds a wrinkle to the implementation, though -- the general > plan still applies. We could either pretend that wchar_t == char, or > we could make an iconv that uses the mb* functions. I see. Yes, this will be a bit trickier, but not much. As far as portability goes, we may have to experiment. But I can tell you flat out that swprintf is going to be a problem; it's a C99 library function and most hosts don't have C99 library extensions. I see that gnulib has at least part of a vasnwprintf implementation... I wonder if they're planning to finish it. > I can implement this, but I'd rather do it only if it is truly needed. > > How are you planning to handle this for Code Sourcery? Really I would > like to hear the answer to this from anybody shipping a gdb > executable. We're really not the ones you have to convince. This is a difficulty-building-GDB issue; commercial distributors only have to get it to build once. And we tend to be limited to mainstream platforms; e.g. 95% of the toolchains CodeSourcery builds are hosted on either Windows (mingw32) or GNU/Linux (RH8, RHEL3). We've used a static GNU libiconv for our Windows tools for ages. People on HP/UX or AIX may have a more interesting time of it. > Daniel> There'd need to be a little additional > Daniel> logic too, to allow you to set all the charset variables at > Daniel> once > > I think "set charset" already does this. It doesn't handle the target > wide charset, but that seems ok in the degraded functionality mode. Right. Except that if the wide charset remains unchanged, validate will report an error since it can't convert to it... -- Daniel Jacobowitz CodeSourcery