From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10014 invoked by alias); 24 Jul 2013 15:16:53 -0000 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 Received: (qmail 9957 invoked by uid 89); 24 Jul 2013 15:16:52 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE autolearn=ham version=3.3.1 Received: from Unknown (HELO mms2.broadcom.com) (216.31.210.18) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 24 Jul 2013 15:16:22 +0000 Received: from [10.9.208.57] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 24 Jul 2013 08:10:01 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 24 Jul 2013 08:16:03 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) with Microsoft SMTP Server id 14.1.438.0; Wed, 24 Jul 2013 08:16:02 -0700 Received: from [10.177.73.66] (unknown [10.177.73.66]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 1C053F2D7B; Wed, 24 Jul 2013 08:16:01 -0700 (PDT) Message-ID: <51EFEFB1.4070408@broadcom.com> Date: Wed, 24 Jul 2013 15:16:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Eli Zaretskii" cc: gdb-patches@sourceware.org Subject: Re: [PING (docs)] Re: [PATCH] [1/2] Add new 'z' format for print command References: <51DAF728.4040309@broadcom.com> <51EFA750.2070707@broadcom.com> <83k3kgvxf2.fsf@gnu.org> In-Reply-To: <83k3kgvxf2.fsf@gnu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00570.txt.bz2 On 24/07/2013 3:34 PM, Eli Zaretskii wrote: > More importantly, I have a difficulty understanding what does > "hexadecimal zero padded to the size ..." mean. More accurately, if > my interpretation of what you say (that 'z' produces "00"s for > non-existing data, then why does this "padding" make sense, when we > are targeting a human consumer? I'm not sure I agree with the "non-existing data" part of your statement, for example a 4-byte register containing the value 1 (one) when printed with /x would print 0x1, with /z it would print 0x00000001, surely the leading 0s do exist, we just normally don't print them. I agree that for a human consumer /z might not be so useful, but moving this code from being MI specific, to being a core format has cleaned up an annoying bug, and does mean that the two interfaces offer the same set of display formats. You might argue that either: (1) We should prevent this format being used in non-mi mode as it is not useful. Given what a small feature this is, and for the consistent interface reason, I'd prefer to keep it available. Or, (2) We allow it, but only document it in the MI part of the document, so CLI users are not 'tempted' to use it. I don't like this as it presupposes what a user will / will not find useful, and make the documentation seem incomplete. I'd be interested to get your thoughts though. Thanks, Andrew