This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: breakpoints/1052: GDB 5.3 (macro supporting) - macro value is string without quotes.
- From: David Carlton <carlton at math dot stanford dot edu>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 13 Feb 2003 20:28:00 -0000
- Subject: Re: breakpoints/1052: GDB 5.3 (macro supporting) - macro value is string without quotes.
- Reply-to: David Carlton <carlton at math dot stanford dot edu>
The following reply was made to PR breakpoints/1052; it has been noted by GNATS.
From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: GNATS Filer <gdb-gnats@sources.redhat.com>,
"Gvozdeva, Svetlana" <Svetlana_Gvozdeva@stl.sarov.ru>
Subject: Re: breakpoints/1052: GDB 5.3 (macro supporting) - macro value is string without quotes.
Date: 13 Feb 2003 12:19:48 -0800
On 13 Feb 2003 16:08:00 -0000, Daniel Jacobowitz <drow@mvista.com> said:
> My point is that "p 234" prints the value of the C expression "234". "p
> var" prints the value of the C expression "var". "p MACRO" is printing
> the value of the C expression "MACRO" which happens to not be a valid
> expression. I don't see a problem with the current behavior.
> Let's see if anyone else has an opinion.
We should definitely keep the current behavior. I suppose we could
add something to 'help print' making it clearer that its argument
should be an expression in the current source language, but the
current behavior is correct: if you want to see what the macro expands
to, use a different command.
For example, say you have
#define MACRO (x + y)
Then 'macro expand MACRO' should print '(x + y)' while 'print MACRO'
should actually look up the variables x and y, figure out their
current values, and add them together. Both of these are useful
operations; trying to have 'print' sometimes do the one and sometimes
do the other (or to have 'print' only do the same as 'macro expand'
instead of what it currently does) would be bad.
David Carlton
carlton@math.stanford.edu