From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26363 invoked by alias); 6 Jul 2007 10:33:35 -0000 Received: (qmail 26355 invoked by uid 22791); 6 Jul 2007 10:33:34 -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; Fri, 06 Jul 2007 10:33:29 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-153-60.inter.net.il [80.230.153.60]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id HEF50086 (AUTH halo1); Fri, 6 Jul 2007 13:33:33 +0300 (IDT) Date: Fri, 06 Jul 2007 10:33:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sourceware.org In-reply-to: <20070705135402.GA4300@caradoc.them.org> (message from Daniel Jacobowitz on Thu, 5 Jul 2007 09:54:02 -0400) Subject: Re: [RFC] Changes to signed char and unsigned char handling Reply-to: Eli Zaretskii References: <20070705135402.GA4300@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/msg00104.txt.bz2 > Date: Thu, 5 Jul 2007 09:54:02 -0400 > From: Daniel Jacobowitz > > 3. Treat "char" as a character, but "unsigned char" and "signed char" > as numbers Didn't RMS object to this change? > Then I updated NEWS, the manual, and the testsuite to match. What do > you think - is this an appropriate resolution for GDB 6.7? All > comments welcome. The change for NEWS is okay with me. The changes for the manual are also okay, but I have a few comments/requests: > +@item s > +@cindex printing strings Please add here a @cindex entry for something like ``printing byte arrays''. > +as strings. @code{unsigned char} and @code{signed char} are displayed as Please include multi-word @code-marked-up text in @w. > @@ -5932,8 +5946,7 @@ displays you request manually using @cod > specify the output format you prefer; in fact, @code{display} decides > whether to use @code{print} or @code{x} depending on how elaborate your > format specification is---it uses @code{x} if you specify a unit size, > -or one of the two formats (@samp{i} and @samp{s}) that are only > -supported by @code{x}; otherwise it uses @code{print}. > +the @samp{i} format, or the @samp{s} format; otherwise it uses @code{print}. This change produces a sentence that is hard to parse: in fact, @code{display} decides whether to use @code{print} or @code{x} depending on how elaborate your format specification is---it uses @code{x} if you specify a unit size, the @samp{i} format, or the @samp{s} format; otherwise it uses @code{print}. The conditions under which `x' is used are described, but the conditions under which we use `i' or `s' are left unspecified. The old text was a bit better, I think, but only a bit: in fact, @code{display} decides whether to use @code{print} or @code{x} depending on how elaborate your format specification is---it uses @code{x} if you specify a unit size, or one of the two formats (@samp{i} and @samp{s}) that are only supported by @code{x}; otherwise it uses @code{print}. In addition, the beginning of the sentence promises some relation between the format used and how elaborate is the format specification, but that relation is left somewhat unclear (this was unclear in the old text as well). I'm guessing that the only relation is whether the unit size is or is not specified, but if that's indeed the only relation, we should make the text less general and talk explicitly about unit size specification. Thanks.