From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22198 invoked by alias); 27 Feb 2007 13:14:59 -0000 Received: (qmail 22188 invoked by uid 22791); 27 Feb 2007 13:14:58 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 27 Feb 2007 13:14:52 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HM2AF-0007bl-EZ; Tue, 27 Feb 2007 08:14:43 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HM2AE-0007FU-Gt; Tue, 27 Feb 2007 08:14:42 -0500 Date: Tue, 27 Feb 2007 18:42:00 -0000 From: Daniel Jacobowitz To: Robert Dewar Cc: Nick Roberts , Jan Kratochvil , mathieu lacage , gdb@sourceware.org Subject: Re: [RFC] Signed/unsigned character arrays are not strings Message-ID: <20070227131442.GA20718@caradoc.them.org> Mail-Followup-To: Robert Dewar , Nick Roberts , Jan Kratochvil , mathieu lacage , gdb@sourceware.org References: <17887.62990.937672.281975@kahikatea.snap.net.nz> <20070224161315.GA27534@caradoc.them.org> <17888.39894.136355.447008@kahikatea.snap.net.nz> <1172390381.2584.18.camel@mathieu> <20070225195350.GA12811@host0.dyn.jankratochvil.net> <20070226004457.GA9926@caradoc.them.org> <17892.4014.160191.285423@kahikatea.snap.net.nz> <45E42969.1030007@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E42969.1030007@adacore.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00272.txt.bz2 On Tue, Feb 27, 2007 at 07:51:53AM -0500, Robert Dewar wrote: > Nick Roberts wrote: > > >That answers the question that we are really asking and justifies the > >patch. > > Not necessarily. First it is only a claim, without documentation, Do you have any reasonable ideas on how to gather data? I'm listening :-) I spent a little while poking at Google CodeSearch. There were definitely some matches of people assigning strings to "unsigned char *" variables - most of the ones I looked at were in test code for crypto libraries, or things like base64 / locale ctype tables. There were an order of magnitude (about 75x) more matches for plain "char *". signed\ char.*\ =\ .*\" about 7000 unsigned\ char.*\ =\ .*\" about 10600 char.*\ =\ .*\" about 753000 I know that as a GDB developer, debugging GDB, I'd want explicitly signed or unsigned characters to be printed as data; we made a deliberate switch to using gdb_byte (which is unsigned char) for unknown data read from target memory. We cast it to char * when we read strings. > second, any incompatible change seems basically problematic. I have some trouble understanding this. Could someone explain it to me? It's an honest and serious question, I'm not asking for a lecture on compatibility concepts here. This is user interface, not core functionality. It's more like clarifying the text of one of GCC's warning messages than changing the dialect of C it accepts. I think we have a lot of freedom to adapt our default output to be more useful to our users, especially when we provide a way to get the old behavior. In this case that method is even completely backwards compatible. I think we have a lot of freedom to make this kind of change. The same reasoning applies to the print/x floating point discussion. > > > We can document how to produce string output more > > > clearly in the manual, perhaps? > > I would instead document more clearly how to produce the integer > output. Without this patch there wasn't any way to produce the integer output for single byte elements. Which drove me batty working with vector registers - I'm glad Jan posted the patch! -- Daniel Jacobowitz CodeSourcery