From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13665 invoked by alias); 11 Feb 2010 14:19:23 -0000 Received: (qmail 13655 invoked by uid 22791); 11 Feb 2010 14:19:22 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Feb 2010 14:19:18 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1BEIsts013791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Feb 2010 09:18:54 -0500 Received: from qcore.mollernet.net (vpn-248-122.phx2.redhat.com [10.3.248.122]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1BEIrJI003149; Thu, 11 Feb 2010 09:18:54 -0500 Message-ID: <4B7411CD.8040702@redhat.com> Date: Thu, 11 Feb 2010 14:19:00 -0000 From: Chris Moller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: pr 11067 patch References: <4B737180.4050802@redhat.com> <20100211092950.GC2907@adacore.com> In-Reply-To: <20100211092950.GC2907@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00288.txt.bz2 On 02/11/10 04:29, Joel Brobecker wrote: >> Provides a little more info on enums for simple 'p' cases; >> keeps the old format for complex cases like structs and arrays: >> > > I feel really bad about this, and I really apologize - I am just only > suddenly wondering why this is considered a good idea, was that discussed? > Please understand that this is not an objection, but I just had a look > at the PR, and I happen to disagree with the reporter. According to me, > he said: > > 1. If I print 'e', GDB prints 'Val1' and that's OK. > 2. If I print 'Val1', GDB prints also prints 'Val1' and he says > that, instead, GDB should print its numerical value. > > I disagree on (2) because, if he wanted the numerical value, he should > have told GDB. For instance: > > (gdb) p GREEN > $1 = GREEN > (gdb) p /d GREEN > $2 = 1 > > If people still think that this suggestion is a good one, I looked at > the patch (the least I could do)... > I personally don't have much of an opinion either way about whether the patch is a good idea--it was on the bug list, they told me to shoot bugs, so I did. But for such a trivial thing, it sure has wasted a lot of bandwidth... I'll fold in your comments below, thx. > >> +Wed Feb 10 17:13:44 2010 Chris Moller >> + >> + PR gdb/11067 >> + * c-valprint.c (c_val_print): In case TYPE_CODE_ENUM, add code to >> + print the numeric value of the enum and the enum tag for >> + top-level, non-summary "print enum"s. >> > > > > >> + if (options->summary || recurse != 0) >> + { >> + fputs_filtered (TYPE_FIELD_NAME (type, i), stream); >> + } >> > > We do not use the curly braces in this case, when the block only contains > one statement. > >