Re: pr 11067 patch

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> Provides a little more info on enums for simple 'p <enum>' cases;
>> keeps the old format for complex cases like structs and arrays:

Joel> I feel really bad about this, and I really apologize - I am just
Joel> only suddenly wondering why this is considered a good idea, was
Joel> that discussed?

A little bit on the archer list, but not really directly.

Joel>   1. If I print 'e', GDB prints 'Val1' and that's OK.
Joel>   2. If I print 'Val1', GDB prints also prints 'Val1' and he says
Joel>      that, instead, GDB should print its numerical value.

Joel> I disagree on (2) because, if he wanted the numerical value, he should
Joel> have told GDB. For instance:

Joel>   (gdb) p GREEN
Joel>   $1 = GREEN
Joel>   (gdb) p /d GREEN
Joel>   $2 = 1

Joel> If people still think that this suggestion is a good one, I looked at
Joel> the patch (the least I could do)...

I asked Chris to work on this because I run into this with some
frequency.  I often will print some enum-typed value and get a symbolic
answer.  Then I have to type another command to get the numeric answer.

It seems mildly friendlier to simply always print it, at least at the
top level.  (In stack traces and in structures it may wind up being too
verbose, hence that decision.)

Differentiating cases 1 and 2 above is not really practical because the
evaluation and printing code are kept separate.

If you disagree strongly, then we could just close the PR and drop it, I
suppose.  I am not very intent on this, I just thought it would be a
nice, if minor, enhancement.  I didn't see a real downside.

Joel> Can you place each statement on their own line? I am guessing that
Joel> GNU indent will fix that anyway, and I also think that this is harder
Joel> to read.

I think we've abandoned any hope of using GNU indent.

Thanks for reviewing this.

Tom