This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: printing wchar_t*


> Date: Thu, 13 Apr 2006 11:06:12 -0700
> From: "Jim Blandy" <jimb@red-bean.com>
> Cc: ghost@cs.msu.su, gdb@sources.redhat.com
> 
> On 4/13/06, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Date: Thu, 13 Apr 2006 10:31:18 -0700
> > > From: "Jim Blandy" <jimb@red-bean.com>
> > > Cc: gdb@sources.redhat.com
> > >
> > > The best approach would be to extend charset.[ch] to handle wide
> > > character sets as well, and then add code to the language-specific
> > > printing routines to use the charset functions.  (This is fortunately
> > > much simpler than adding support for multibyte characters.)
> >
> > Can you tell why you think it's much simpler?
> 
> Okay --- just to be clear, this is about multi-byte characters, not
> wide characters, which is what Volodya was asking about.

It's both, as far as I'm concerned: I was asking to explain why you
think supporting wide characters is much easier than supporting
multi-byte characters.

> - I don't think GDB should use off-the-shelf conversion stuff like
> iconv.  For example, if you're looking at ISO-2022 text with the
> character set switching escape codes in there, I'd argue it'd be wrong
> for GDB to display those strings without showing the escape codes. 
> It's a debugger, so people are looking at strings and corresponding
> indexes into those strings, and they need to be able to see exactly
> what's in there.  iconv handles the escape codes silently.

If we add such a support, we should probably have GDB print both the
raw and printable representation of the non-ASCII strings.  We already
do something similar with char data type.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]