From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2990 invoked by alias); 7 Jul 2007 10:04:00 -0000 Received: (qmail 2978 invoked by uid 22791); 7 Jul 2007 10:03:59 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 07 Jul 2007 10:03:57 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-229-118-143.inter.net.il [84.229.118.143]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id HEK29166 (AUTH halo1); Sat, 7 Jul 2007 13:03:59 +0300 (IDT) Date: Sat, 07 Jul 2007 10:04:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sourceware.org In-reply-to: <20070706213408.GA5154@caradoc.them.org> (message from Daniel Jacobowitz on Fri, 6 Jul 2007 17:34:08 -0400) Subject: Re: [RFC] Changes to signed char and unsigned char handling Reply-to: Eli Zaretskii References: <20070705135402.GA4300@caradoc.them.org> <20070706213408.GA5154@caradoc.them.org> X-IsSubscribed: yes 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: 2007-07/txt/msg00126.txt.bz2 > Date: Fri, 6 Jul 2007 17:34:08 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sourceware.org > > > Didn't RMS object to this change? > > His objection was to the original change, which is currently in HEAD, > to not print "unsigned char *" variables as strings. It was not an > especially definitive objection; I think that this version is better > than the behavior of earlier versions of GDB, which would satisfy his > stated concern. Well, maybe we should ask for his opinion on your suggested patch. > > The conditions under which `x' is used are described, but the > > conditions under which we use `i' or `s' are left unspecified. > > We don't use `i' or `s'; the use of `i' or `s' in the user's format > specification causes `display' to behave like `examine' instead of > like `print'. How is this? > > in fact, @code{display} decides > whether to use @code{print} or @code{x} depending on your format > specification---@code{display} uses @code{x} if you specify a unit size, > the @samp{i} format, or the @samp{s} format; otherwise it uses @code{print}. Aha, I see that I was doubly confused. So maybe this is more clear yet: in fact, @code{display} decides whether to use @code{print} or @code{x} depending on your format specification---it uses @code{x} if you specify either the @samp{i} or @samp{s} format, or a unit size; otherwise it uses @code{print}.