question about c-lang.c

question about c-lang.c

[Tom Tromey]

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.

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?

Tom


#include <stdio.h>

char *c = "\00001";

int main ()
{
  printf ("%s\n", c);
  return 0;
}


Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* 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;

Re: question about c-lang.c

[Andrew Cagney]

> 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 <stdio.h>
> 
> char *c = "\00001";
> 
> int main ()
> {
>   printf ("%s\n", c);
>   return 0;
> }
> 
> 
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
> 	* 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;
> 

Re: question about c-lang.c

[Fred Viles]

On 12 Sep 2002 at 17:44, Andrew Cagney wrote about
    "Re: question about c-lang.c":

| > 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'.

Right.

|...
| > 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?

Looks to me like c_emit_char() is called both for char and string 
cases.  So char c = '\0'; would result in
(gdb) print c
$1 = '\000'
rather than
$1 = '\0'

From the change log, it looks like GDB used to work this way and was 
patched last December to get the current (wrong for strings) 
behavior.

Maybe making the output conditional on (quoter == '\'') would allow 
for both cases.

- Fred

Re: question about c-lang.c

[Tom Tromey]

>>>>> "Fred" == Fred Viles <fv@epitools.com> writes:

Fred> Maybe making the output conditional on (quoter == '\'') would
Fred> allow for both cases.

I'll update my patch and write a test case.
It might be a while though.  I only do gdb hacking on a free time basis.

Tom

Re: question about c-lang.c

[Andrew Cagney]

>>>>>> "Fred" == Fred Viles <fv@epitools.com> writes:
> 
> 
> Fred> Maybe making the output conditional on (quoter == '\'') would
> Fred> allow for both cases.
> 
> I'll update my patch and write a test case.
> It might be a while though.  I only do gdb hacking on a free time basis.

Create a bug report then :-)

Andrew