Re: printing wchar_t*

[Daniel Jacobowitz <drow@false.org>]

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