Re: PR11067 patch

[Chris Moller <cmoller at redhat dot com>]

On 02/08/10 16:54, Tom Tromey wrote:
> > > > > > "Chris" == Chris Moller<cmoller@redhat.com>  writes:
> > > > > >              
>
> Chris>  The attached patch fixes bug 11067 "p<enum constant>  should print the
> Chris>  constant's value" by providing a means of setting a format string to
> Chris>  be used in printing enums.  The string is set with
>
> Chris>     set enum-fmt<string>
>
> I would rather not introduce a new option for this, particularly a
> formatting option.  We don't have this sort of thing elsewhere in gdb --
> we just pick a printing format or two.
>    

The argument still applies that, no matter which format(s) are defined 
for multifaceted data (in this case, numeric value, symbolic value, and 
enum tag), it's not going to meet everyone's needs--the discussion on 
this thread demonstrates that fairly well.  The patch I'm suggesting 
offers the flexibility to easily define, using a simple, printf-like 
format string, without the necessity of writing Python code or whatever, 
any format people find useful.

The patch I'm suggesting is completely transparent to people who don't 
use it.  The presence of the set enum-fmt operation can be utterly 
ignored, with no loss of existing gdb capability,  by people who don't 
need it, but at the same time offers flexibility to people who can make 
use of it.

The same mechanism, BTW, could be used for other presently fixed-format 
multifaceted data such as characters (including, possibly, multibyte, 
UTF-style or wchar_t, characters, if gdb supports that kind of thing, 
but I haven't looked in detail at this.).  The mechanism also, BTW, 
introduces very little additional overhead in printing values--the user 
specified format string is translated, once, when set, into a printf 
format string subsequently used by vfprintf_filtered.

> I re-read the thread on the archer list.  I propose having it print
> like:
>
> $2 = ENUMERATOR = (enum tag) 23
>
> However, i would suppress the extra stuff in structs and when printing
> in summary mode.
>    

It's certainly possible to provide for multiple formats that are 
selected based on context--the only thing I don't know just off hand is 
how to determine that context.

> Tom
>