Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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