From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23994 invoked by alias); 9 Feb 2010 17:31:43 -0000 Received: (qmail 23985 invoked by uid 22791); 9 Feb 2010 17:31:43 -0000 X-SWARE-Spam-Status: No, hits=-7.2 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; Tue, 09 Feb 2010 17:31:36 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o19HVZpQ030309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Feb 2010 12:31:35 -0500 Received: from qcore.mollernet.net (vpn-8-119.rdu.redhat.com [10.11.8.119]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o19HVYQJ001904; Tue, 9 Feb 2010 12:31:34 -0500 Message-ID: <4B719BF6.1040207@redhat.com> Date: Tue, 09 Feb 2010 17:31: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: tromey@redhat.com CC: gdb-patches@sourceware.org Subject: Re: PR11067 patch References: <4B6D70A3.2090208@redhat.com> In-Reply-To: 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/msg00259.txt.bz2 On 02/08/10 16:54, Tom Tromey wrote: >>>>>> "Chris" == Chris Moller writes: >>>>>> > > Chris> The attached patch fixes bug 11067 "p 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 > > 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 >