From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11570 invoked by alias); 27 Feb 2007 22:38:27 -0000 Received: (qmail 11561 invoked by uid 22791); 27 Feb 2007 22:38:27 -0000 X-Spam-Check-By: sourceware.org Received: from exprod8og56.obsmtp.com (HELO exprod8og56.obsmtp.com) (64.18.3.94) by sourceware.org (qpsmtpd/0.31) with SMTP; Tue, 27 Feb 2007 22:38:18 +0000 Received: from source ([12.110.134.31]) by exprod8ob56.obsmtp.com ([64.18.7.12]) with SMTP; Tue, 27 Feb 2007 14:37:01 PST Received: from pkoning.equallogic.com ([172.16.1.118]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 17:37:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17892.45762.519048.501270@gargle.gargle.HOWL> Date: Wed, 28 Feb 2007 00:47:00 -0000 From: Paul Koning To: mark.kettenis@xs4all.nl Cc: drow@false.org, eliz@gnu.org, dewar@adacore.com, nickrob@snap.net.nz, jan.kratochvil@redhat.com, Mathieu.Lacage@sophia.inria.fr, gdb@sourceware.org Subject: Re: [RFC] Signed/unsigned character arrays are not strings 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> <20070227131442.GA20718@caradoc.them.org> <20070227215316.GA26262@caradoc.them.org> <200702272211.l1RMBVvI028239@brahms.sibelius.xs4all.nl> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid 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/msg00288.txt.bz2 >>>>> "Mark" == Mark Kettenis writes: >> Date: Tue, 27 Feb 2007 16:53:16 -0500 From: Daniel Jacobowitz >> >> >> On Tue, Feb 27, 2007 at 11:06:17PM +0200, Eli Zaretskii wrote: > >> Doesn't a similar situation exist with "unsigned int" and "int", >> or > with "unsigned long" and "long"? And yet we don't treat them >> > differently. >> > >> > IOW, I think it's quite expected that explicit signedness is > >> relatively rare, since in the vast majority of cases it is simply >> not > needed. Interpreting this phenomenon as saying something >> about what > kind of data is stored is not necessarily a good >> idea. >> >> I feel that this is different for two reasons. One is that the >> situation for int and long is not the same, because "int" and >> "signed int" are the same type in C - but "char" and "signed char" >> are not. Char is explicitly of indeterminate sign. The other is >> that there is a widespread use of "char" for string data and >> "signed char" or "unsigned char" for non-string data. Mark> Well, "char" really is "signed char" on most machines and Mark> "unsigned char" on others. One way to prevent the Mark> sign-extension problems this sometimes causes, is to explicitly Mark> use "unsigned char *" for strings. Right. For example, if you do string manipulation by table lookup on the characters, then this is a good thing to do. (It avoids the painful 384 entry table hacks you otherwise need.) Mark> Anyway, I'm in favour of restore the traditional gdb behaviour Mark> of printing all three as strings. Same here. paul