Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Holger Hans Peter Freyther <holger@freyther.de>, teawater@gmail.com
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Empty if body in linux-record.c
Date: Mon, 15 Mar 2010 01:00:00 -0000	[thread overview]
Message-ID: <20100315010047.GG3045@adacore.com> (raw)
In-Reply-To: <201003141348.24756.holger@freyther.de>

> this is one the issues reported by "clang --analyze" and it appears to
> me that the code was broken in the same way since the initial check-in
> of these routines, looking at the tests in gdb.record it does not appear
> that these are covered at all.

I think you are right. Hui should be able to confirm that the code
was indeed broken and that the trailing semicolon was not intended.

> I'm not really known to the patch contribution of gdb so I'm not sure if I'm
> following the proper process here...anyway here is a patch with a
> ChangeLog entry.

Pretty good for a first try :). Just a couple of comments:

  1. You should indicate how you tested this. Normally, you run
     the testsuite before and after, and compare the associated gdb.sum
     file, to make sure that you did not introduce any regression.

     In this particular case, you also need to make sure that process
     record testing is activated, which it is not by default.
     Please have a look at
     http://sourceware.org/gdb/wiki/ProcessRecord#Testing.

   2. Your ChangeLog entry is much too verbose:

> 	* linux-record.c (record_linux_msghdr): Fix a compiler warning
> 	about an empty if body that has existed since the addition of the
> 	code. This change will change the return value of the function from
> 	always returning -1 to returning -1 only if calling record_arch_list_add_mem
> 	is failing. The inner for loop will also be iterated more than once
> 	now.

      You just need to say *what* you've done, not why or how.
      This is explained in more details in the Gnu Coding Standards
      manual. (I sometimes indulge myself, and add an explaination,
      but it's because it's a very very short one)

      On possibility would be:

      * linux-record.c (record_linux_msghdr): Remove unintended semicolons.

Would you like write access to the GDB repository?

-- 
Joel


  reply	other threads:[~2010-03-15  1:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-14 12:49 Holger Hans Peter Freyther
2010-03-15  1:00 ` Joel Brobecker [this message]
2010-03-16  8:01   ` Hui Zhu
2010-03-16 15:02     ` Joel Brobecker
2010-03-16 15:59       ` Joel Brobecker
2010-03-16 17:13         ` Hui Zhu
2010-03-17  0:42           ` Holger Hans Peter Freyther

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=20100315010047.GG3045@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=holger@freyther.de \
    --cc=teawater@gmail.com \
    /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