From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Chris Moller <cmoller@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: pr 11067 patch
Date: Sat, 13 Feb 2010 11:49:00 -0000 [thread overview]
Message-ID: <20100213114933.GA595@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <4B75783D.6050103@redhat.com>
Hi Chris,
On Fri, 12 Feb 2010 16:48:13 +0100, Chris Moller wrote:
> --- gdb/testsuite/gdb.mi/mi-var-display.exp 1 Jan 2010 07:32:03 -0000 1.34
> +++ gdb/testsuite/gdb.mi/mi-var-display.exp 12 Feb 2010 15:38:07 -0000
> mi_gdb_test "-var-evaluate-expression anone" \
> - "\\^done,value=\"A\"" \
> + "\\^done,value=\"A = \\(enum <anonymous>\\)0\"" \
> "eval variable anone"
While it works with Eclipse should this format be used even for MI?
MI doc says:
returns its value as a string.
It is true it may be the same what `print' doc says:
By default, GDB prints a value according to its data type.
Still IMO the representation "A = (enum <anonymous>)0" is not suitable for MI
as it is not the intended type of a C expression.
But in practice for Eclipse it works and it brings better user experience - as
in CLI.
Some GNU Coding Standard nitpicks:
> Index: gdb/ChangeLog$
> +Wed Feb 10 17:13:44 2010 Chris Moller <moller@mollerware.com>
timestamp line does not follow GCS.
> + /*
> + When printing a simple enum value, the following code includes, in
> + addition to the symbolic value, the numeric value and the enum tag.
> + Under other-than-simple circumstances--in structs, arrays, etc.--
> + it does what's always done and prints just the symbolic value.
> + */
GCS comment should be formatted:
/* text...
text. */
> + else if (TYPE_TAG_NAME(type))
> + enum_name = TYPE_TAG_NAME(type);
GCS spacing: -> "TYPE_TAG_NAME (type)"
> + else
> + enum_name = "<anonymous>";
> +
= +^I $
git diff --check says:
gdb/c-valprint.c:433: trailing whitespace.
(but unaware how to check an already axisting .patch file)
> + fprintf_filtered (stream, "%s = (enum %s)%s",
->
# + fprintf_filtered (stream, "%s = (enum %s) %s",
while PR 11067 shows it that way GCS 5.3 suggests a whitespace there:
foo = (char *) malloc (sizeof *foo);
> +++ gdb/testsuite/gdb.base/pr11067.c 12 Feb 2010 15:38:05 -0000
> @@ -0,0 +1,48 @@
> +enum E {
> + Val1 = 56,
> + Val2
> +};
According to GNU indent it should be:
enum E
{
Val1 = 56,
Val2
};
> +struct Es {
ditto
> +int main() {
GCS:
int
main ()
{
> + /*
> + The following is a fake-out for linkers (such as, apparently, the AIX
> + linker) that optimises out unreference variables.
> + */
Comment -> GCS.
> + return 0;
> +}
> +
trailing whitespace line.
> +++ gdb/testsuite/gdb.base/pr11067.exp 12 Feb 2010 15:38:05 -0000
> +gdb_test "print e" "Val1 = \\(enum E\\)56"
> +
> +gdb_test "print ea" "{Val1, Val2, Val1}"
> +
Two spaces.
GDB testscases use more a practice to expect also leading " = ":
gdb_test "print e" " = Val1 = \\(enum E\\)56"
gdb_test "print ea" " = {Val1, Val2, Val1}"
> +gdb_test "print es" "v = 5, e = Val2}"
+ IMO missing opening bracket.
gdb_test "print es" " = {v = 5, e = Val2}"
Regards,
Jan
next prev parent reply other threads:[~2010-02-13 11:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-11 2:55 Chris Moller
2010-02-11 9:30 ` Joel Brobecker
2010-02-11 14:19 ` Chris Moller
2010-02-11 19:50 ` Tom Tromey
2010-02-12 4:11 ` Joel Brobecker
2010-02-12 15:48 ` Chris Moller
2010-02-13 11:49 ` Jan Kratochvil [this message]
2010-02-13 18:56 ` Chris Moller
2010-02-19 14:28 ` Joel Brobecker
2010-02-19 14:36 ` Jan Kratochvil
2010-02-19 14:45 ` Joel Brobecker
2010-02-19 14:54 ` Chris Moller
2010-02-19 18:50 ` Jan Kratochvil
2010-02-19 19:52 ` Chris Moller
2010-02-19 20:11 ` Jan Kratochvil
2010-02-22 9:22 ` Vladimir Prus
2010-02-23 23:55 ` Tom Tromey
2010-03-11 15:44 ` pr 11067 patch resurrected from the dead Chris Moller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100213114933.GA595@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=cmoller@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox