Re: printing wchar_t*

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 14, 2006 at 05:08:17PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 14 Apr 2006 09:05:27 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> > 
> > 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?
> 
> How about "print elements until you find X", where X is any 8-bit
> code, including zero?  That would useful in situations, I think.

Well, I suppose.  But in the general case, there's always user-defined
functions, and hopefully better scripting languages in the future;
is this something that will be frequently useful direct from the
command line?

It'll involve another extension to the language expression parsers, you
see.  We ought to minimize such extensions; e.g. the set of operators
available is fairly limited.

I was thinking "print *ptr@@", by analogy to "print *ptr@5".  Or we
could use the existing @ N syntax.  Right now we issue errors for
anything less than one; so how about "print *ptr@0" for "print *ptr
until you encounter a zero"?

> We will probably need some user-settable limit for the max number of
> elements, to avoid running amok in case there's no X.

We can just use the "set print elements" limit for that.  Although,
it's always bugged me that we use the same setting for "number of
members of an array" and "number of characters in a string"; I usually
want only a few elements of an array, but much more of a string.  Maybe
someday we should separate them.

> I think we cannot assume Unicode is the only character set, but we can
> make Unicode the default and let the user say otherwise if not.

Seems reasonable to me.

-- 
Daniel Jacobowitz
CodeSourcery