This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: printing wchar_t*
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