This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR 11067

On 02/03/10 18:28, Daniel Jacobowitz wrote:
On Wed, Feb 03, 2010 at 03:25:06PM -0800, Roland McGrath wrote:
Yeah, I was going for parity and the /c format would not have been my first
choice if we didn't already have it.  I think:

$2 = (enum frobozz) 1 = ENUM1

would be fine too, or maybe reverse the clauses. "(type) digit" is
probably what's most likely always to be pasteable anywhere, in case
it's into a context where you don't have the same scope for the enum
constant (in C++).

Something to consider is what contexts you want this output in. I think this would get old really fast:

$2 = { code = CODE_ADD = (enum code) 1, ops = OPS_TWO = (enum ops) 2 }


$2 = { code = CODE_ADD, ops = OPS_TWO }
(gdb) p CODE_ADD
$3 = CODE_ADD = (enum code) 1

Hmm, can't say I like that format any better either, but there's got
to be a good one. I usually p/d CODE_ADD to find out the value...

While I was looking for where this stuff is formatted, I noticed it goes through python/py-prettyprint.c which, I assume, can format things any way you like it. How about just something generic by default and use a pretty-print thingy if that doesn't work? (Uh, assuming py-prettyprint.c does that....)

My takeaway point here is to consider the overall impact.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]