This is the mail archive of the 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*

On 4/13/06, Eli Zaretskii <> wrote:
> > Date: Thu, 13 Apr 2006 10:31:18 -0700
> > From: "Jim Blandy" <>
> > Cc:
> >
> > 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.

- The code for limiting how much of a string GDB will print, and for
detecting repetitions, seemed like it would be hard to adapt to
multibyte encodings.  Remember that you've got to be completely
agnostic about the encoding; there are stateful encodings out there in
widespread use, etc.

- 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.

- Most programs can just print an error message and die if they see
ill-formed multi-byte sequences: you gave them junk; fix it.  GDB
needs to do something more useful; its job is to be helpful exactly
when your program is misbehaving and you don't know why.

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