From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20536 invoked by alias); 12 Sep 2002 21:44:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20529 invoked from network); 12 Sep 2002 21:44:42 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 12 Sep 2002 21:44:42 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7F0503C44; Thu, 12 Sep 2002 17:44:39 -0400 (EDT) Message-ID: <3D810AC7.5040306@ges.redhat.com> Date: Thu, 12 Sep 2002 14:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tromey@redhat.com Cc: Gdb List Subject: Re: question about c-lang.c References: <87k7lta0g6.fsf@fleche.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00131.txt.bz2 > Today I happened to read c-lang.c:c_emit_char(). > > Suppose a string contains the characters \0 (nul), `0' and finally `1'. > (See appended source.) > > Now print this string: > > (gdb) p *c @ 4 > $2 = "\001" > > This output is ambiguous, as \001 has another meaning. Isn't it simply wrong? A C parser would treat that as '\1'. > I believe this is a problem for programs using MI. They can't > correctly parse this output (should they want to). > > > I've appended one possible fix. This isn't ideal since it also > changes how char literals are printed. Perhaps that is acceptable? How are char literals changed? Anyway, check this: (gdb) cagney@b1$ gdb a.out GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (gdb) b main Breakpoint 1 at 0x80483e3: file c.c, line 7. (gdb) run Starting program: /tmp/a.out Breakpoint 1, main () at c.c:7 7 printf ("%s\n", c); (gdb) print c $1 = 0x8048407 "" (gdb) print *c@4 $3 = "\00001" (gdb) So regardless you've got a regression! The patch is approved. Can you also add to a testcase? Andrew > Tom > > > #include > > char *c = "\00001"; > > int main () > { > printf ("%s\n", c); > return 0; > } > > > Index: ChangeLog > from Tom Tromey > > * c-lang.c (c_emit_char): Don't treat \0 specially. > > Index: c-lang.c > =================================================================== > RCS file: /cvs/src/src/gdb/c-lang.c,v > retrieving revision 1.13 > diff -u -r1.13 c-lang.c > --- c-lang.c 11 Jul 2002 13:50:49 -0000 1.13 > +++ c-lang.c 10 Sep 2002 23:26:06 -0000 > @@ -78,9 +78,6 @@ > case '\007': > fputs_filtered ("\\a", stream); > break; > - case '\0': > - fputs_filtered ("\\0", stream); > - break; > default: > fprintf_filtered (stream, "\\%.3o", (unsigned int) c); > break; >