From: Pedro Alves <pedro@codesourcery.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [ob] remote.c, eliminate unused variables
Date: Wed, 05 May 2010 22:39:00 -0000 [thread overview]
Message-ID: <201005052339.07578.pedro@codesourcery.com> (raw)
In-Reply-To: <4BE1EF9C.8070807@vmware.com>
On Wednesday 05 May 2010 23:22:20, Michael Snyder wrote:
> >> Can't guarantee it, no.
> >> I'm making sure the semantics isn't changed, but I can't always
> >> be sure that the original semantics was right.
> >
> > Well, then I'll ask please, don't "fix" more things like this,
> > and surely don't call it obvious. You're removing a warning for
> > the sake of it.
>
> No, I'm attempting to make the code easier to understand by
> removing dead code and variables. Since this warning is
> turned off, I'm not even reducing the number of warnings.
You're hiding the bug for whoever wants to catch these
bugs by enabling the warning in its local tree. That's what
I mean: you must be enabling the warning explicitly to see
these; if one doesn't want to check if the warnings are
pointing at something wrong, then one just shouldn't enable
the warning in the first place.
> > A warning is useful as a hint at something
> > wrong with the code; there may be something genuinely wrong
> > with it. Removing it blindly removes the useful hint.
>
> There's no hint if the warning is turned off. If I hadn't
> touched it and you hadn't reviewed my change, it would have
> remained undiscovered indefinitely.
I'll see it the same way you must be seeing it. By
enabling the warning on my local build.
> So let's fix it, shall we? I'll post a separate patch for you to review.
To be clear, I'm very much not interested in reviewing these
kind of patches. That would mean doing about the same work
the person writing the patch is already doing. What I'm intersted
in, is making sure that whenever these patches go in, it was made sure
the variables weren't being unused because we forgot to use
them, instead of just deleting them. If there's any doubt
that's the case, then the patch isn't obvious, and it should
be posted for comments.
> > If you
> > want to be bothered to look at the code to see if there's
> > something else genuinely wrong, then please, don't change it.
>
> That's not fair, I did "bother" to look at the code.
> One got by me, that's all. Thanks for catching it.
Okay, thanks. I misunderstood perhaps, your reply seemed
to imply you didn't ("Are you making sure" -> "Can't guarantee it, no").
--
Pedro Alves
next prev parent reply other threads:[~2010-05-05 22:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 20:47 Michael Snyder
2010-05-05 20:51 ` Pedro Alves
2010-05-05 21:14 ` Michael Snyder
2010-05-05 21:41 ` Pedro Alves
2010-05-05 22:22 ` Michael Snyder
2010-05-05 22:39 ` Pedro Alves [this message]
2010-05-07 17:42 ` Tom Tromey
2010-05-07 18:51 ` Michael Snyder
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=201005052339.07578.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.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