From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21186 invoked by alias); 14 Apr 2006 13:05:34 -0000 Received: (qmail 21178 invoked by uid 22791); 14 Apr 2006 13:05:34 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 14 Apr 2006 13:05:32 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FUNzM-0003TL-0y; Fri, 14 Apr 2006 09:05:28 -0400 Date: Fri, 14 Apr 2006 13:07:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: printing wchar_t* Message-ID: <20060414130527.GA12955@nevyn.them.org> Mail-Followup-To: Vladimir Prus , Eli Zaretskii , gdb@sources.redhat.com References: <200604141257.41690.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604141257.41690.ghost@cs.msu.su> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00180.txt.bz2 On Fri, Apr 14, 2006 at 12:57:41PM +0400, Vladimir Prus wrote: > > So if you are going to do this in the front-end, I think all you need > > is ask GDB to supply the wchar_t string using the array notation; the > > rest will have to be done inside the front-end. Am I missing > > something? > > Yes, I'll need to know the length of the string. I can do this either using > user-defined gdb command (which again will solve *my* problem, but be a local > solution), or by looking at each character until I see zero, in which case > I'd need to command for each characters. Going away from GDB support for wide characters for a moment, and back to this; we have a "print N elements" notation; should we extend it to a "print all non-zero elements" notation? Alternatively, we could do it specially by recognizing wchar_t, but I think the general solution might be more useful. A user defined command for this isn't all that bad, though. You can hopefully define the user command from your frontend. I haven't tested this much, but I don't see a reason why it shouldn't work. If you use define through -interpreter-exec you get CLI prompts back; ugh, that's nasty. If you try this: -interpreter-exec console "define foo\nend" It gets treated as junk. Should we make multi-line strings work in -interpreter-exec? > Deciding if it's UTF-16 or UTF-32 is not the problem. In fact, exactly the > same code will handle both encodings just fine. The question if we allow > encodings which are not UTF-16 or UTF-32. I don't know about any such > encodings, but I'm not an i18n expert. Eli'd know better than me, but I think that expecting wchar_t to be Unicode is not reliable. The glibc manual suggests that it's valid to use other encodings for wchar_t, although ISO 10646 is typical. -- Daniel Jacobowitz CodeSourcery