From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11546 invoked by alias); 20 Jan 2004 19:15:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11530 invoked from network); 20 Jan 2004 19:15:14 -0000 Received: from unknown (HELO gollum.inter.net.il) (192.114.186.22) by sources.redhat.com with SMTP; 20 Jan 2004 19:15:14 -0000 Received: from zaretski (pns03-206-161.inter.net.il [80.230.206.161]) by gollum.inter.net.il (Mirapoint Messaging Server MOS 3.3.8-GR) with ESMTP id CFR41715; Tue, 20 Jan 2004 21:14:31 +0200 (IST) Date: Tue, 20 Jan 2004 19:15:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-Id: <2719-Tue20Jan2004211055+0200-eliz@elta.co.il> CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20040120145225.GA10459@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 20 Jan 2004 09:52:25 -0500) Subject: Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted Reply-to: Eli Zaretskii References: <1031212221704.ZM22539@localhost.localdomain> <3FDA636F.30204@redhat.com> <400C58E6.4070908@redhat.com> <400C60C0.9040702@gnu.org> <20040119231853.GA6132@nevyn.them.org> <400C7948.9060300@gnu.org> <20040120012252.GA4828@nevyn.them.org> <400C8CC0.3040706@gnu.org> <20040120054836.GA23548@nevyn.them.org> <2427-Tue20Jan2004085108+0200-eliz@elta.co.il> <20040120145225.GA10459@nevyn.them.org> X-SW-Source: 2004-01/txt/msg00560.txt.bz2 > Date: Tue, 20 Jan 2004 09:52:25 -0500 > From: Daniel Jacobowitz > > > Daniel, do you object to having the feature you wanted in `x', rather > > than in `print'? If you do, could you please explain why? > > Because, at the moment, we have a common syntax shared by print and > examine - but some of the options don't make sense (I claim) for print. > But they do all make sense for examine. Sorry, I don't see how is this relevant. Suppose we add a new format letter to `x', one that doesn't exist in `print'--would that be okay, and if not, why not? > I don't think that it is a maintenance command We have wuite a few examples of obscure features that we pushed to maint. I don't see why this one cannot. I do agree that it's better to have it on a regular command. > I also think that adding a new print format flag that examines > without changing the existing ones will be more confusing. Please tell why. I don't see why it would be confusing to add a new format that is defined to always show the memory representation of the value in hex.