From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC/PATCH] Clean up unused variables (and prepare for `-Wunused-variable' flag)
Date: Tue, 24 Apr 2012 18:10:00 -0000 [thread overview]
Message-ID: <m3pqaxqa5t.fsf@redhat.com> (raw)
In-Reply-To: <4F968B4D.3050209@redhat.com> (Pedro Alves's message of "Tue, 24 Apr 2012 12:15:25 +0100")
On Tuesday, April 24 2012, Pedro Alves wrote:
> Hi Sérgio,
>
> First off, thanks for doing this.
Thanks for reviewing.
> On 04/23/2012 11:51 PM, Sergio Durigan Junior wrote:
>
>> Hi,
>>
>> This patch is a followup of the discussion in:
>>
>> http://sourceware.org/ml/gdb/2012-04/msg00171.html>
>> First of all, I am sorry for the size of this patch, but I couldn't
>> think of a good way of splitting it, and also I thought it would be
>> useless since these changes are all logically related.
>
>
> It's not useless at all. This warning points at two classes of problems:
>
> - variables that are no longer necessary, and can be garbage collected.
> - variables that actually should be being used, but they're not due to
> some latent bug.
>
> I skimmed the patch, and noted several places, mostly in tdep code, where
> you end up removing more than the unsuspecting auxiliary and obviously-left-
> -behind-by-accident variable. Some of those removed bits could well be latent
> bugs. Some hunks seem to remove used variables and expand what they were
> initialized from at the used sites. What's up with that? Please give rationale
> for any change that requires more than idle brain power to understand.
> :-)
We already talked on IRC, but I'm replying this message for the sake of
keep the record. As I said, initially I thought that those
initialized-but-not-used cases were copy-and-paste mistakes. But thanks
for pointing that. Here's what I'm going to do:
- Split these cases by arch, and resubmit it so that the maintainers of
each arch will get a chance to review and see if the case is a latent
bug or not
- Split and commit the obvious bits, as approved by Tromey and you in
the other message in this thread.
>> I'd like to apply it, but I have a couple of questions before:
>>
>> a) How's the ChangeLog for this patch supposed to be? Can I make a
>> "generic" ChangeLog, saying something like `Remove unused variables from
>> files'?
>>
>> b) I'd like someone to take a look at the `observer.sh' change, please.
>
>
> Please sent it as a separate patch, along with a rationale.
> Also, the .c files under features/ are generated files. We'll need to fix
> the generator instead, again, best done as a separate patch.
Thanks, I totally forgot about this fact! And I can't believe I didn't
read the header comment on the top of those files :-). Anyway, this
change will go as a separate patch as well.
--
Sergio
next prev parent reply other threads:[~2012-04-24 18:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 23:05 Sergio Durigan Junior
2012-04-24 3:33 ` Doug Evans
2012-04-24 18:02 ` Sergio Durigan Junior
2012-04-24 12:16 ` Pedro Alves
2012-04-24 17:38 ` Jan Kratochvil
2012-04-24 17:42 ` Tom Tromey
2012-04-24 17:51 ` Pedro Alves
2012-05-02 5:30 ` Sergio Durigan Junior
2012-05-02 6:17 ` Michael Eager
2012-05-02 10:55 ` Pedro Alves
2012-05-18 18:46 ` Sergio Durigan Junior
2012-05-18 19:13 ` Tom Tromey
2012-05-18 21:05 ` Sergio Durigan Junior
2012-04-24 17:53 ` Sergio Durigan Junior
2012-04-24 20:07 ` Tom Tromey
2012-04-24 18:10 ` Sergio Durigan Junior [this message]
2012-04-24 17:49 ` Tom Tromey
2012-04-24 18:11 ` Doug Evans
2012-04-24 20:30 ` Joel Brobecker
2012-04-24 17:58 ` [PATCH] Refactor observer.sh to cleanup unused vars (was: [RFC/PATCH] Clean up unused variables (and prepare for `-Wunused-variable' flag)) Sergio Durigan Junior
2012-04-24 17:59 ` [PATCH] Refactor observer.sh to cleanup unused vars Tom Tromey
2012-04-24 18:11 ` Sergio Durigan Junior
2012-04-24 18:04 ` Pedro Alves
2012-05-14 11:37 ` [PATCH] Refactor observer.sh to cleanup unused vars (was: [RFC/PATCH] Clean up unused variables (and prepare for `-Wunused-variable' flag)) Jan Kratochvil
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=m3pqaxqa5t.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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