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 21:41:00 -0000 [thread overview]
Message-ID: <201005052241.14753.pedro@codesourcery.com> (raw)
In-Reply-To: <4BE1DFA9.9060607@vmware.com>
On Wednesday 05 May 2010 22:14:17, Michael Snyder wrote:
> Pedro Alves wrote:
> > On Wednesday 05 May 2010 21:46:55, Michael Snyder wrote:
> >> --- remote.c 5 May 2010 15:05:57 -0000 1.405
> >> +++ remote.c 5 May 2010 20:43:46 -0000
> >> @@ -2512,8 +2512,8 @@ remote_threads_info (struct target_ops *
> >> {
> >> struct gdb_xml_parser *parser;
> >> struct threads_parsing_context context;
> >> - struct cleanup *back_to = make_cleanup (null_cleanup, NULL);
> >>
> >> + make_cleanup (null_cleanup, NULL);
> >
> > Are you making sure (in all your patches) that the reason the
> > variables are unused isn't itself a bug?
>
> 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. 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. 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.
> > In this case, creating a
> > null_cleanup and not storing a pointer anywhere is
> > highly suspicious...
>
> Well, then it was wrong when I got there. The variable that
> it was stored to was not used, but shadowed an outer scope variable
> of the same name, which was used.
>
> Maybe it should have stored it without declaring it?
Store what? What do you mean?
> I don't know... what do you think?
null_cleanup's only serve one single purpose --- to
introduce a new cleanup scope, so you can do things like:
struct cleanup *old_chain = make_cleanup (null_cleanup, NULL);
...
foo = xmalloc (big_chunk);
make_cleanup (xfree, foo);
...
bar = xmalloc (big_chunk2);
make_cleanup (foo, bar);
...
baz = xmalloc (big_chunk3);
make_cleanup (bar, baz);
...
do_cleanup (old_chain);
Note no pointer is stored for the intervening cleanups.
In this particular case, in remote.c, there's no other cleanup
created in the scope in question, and the outer scope already
has a proper do_cleanups, so the right thing to do is to
remove the whole `make_cleanups (null_cleanup, NULL)' line.
But, and here's the genuine bug, if gdb_xml_parse throws
midway while parsing the xml, there's no cleanup set to
release `context.items'. There's an usual pattern around
all these `gdb_xml_create_parser_and_cleanup' calls that
this particular case isn't following (and the cleanup in
question may indicate that it was simply forgotten, and
so the warning was being useful).
--
Pedro Alves
next prev parent reply other threads:[~2010-05-05 21:41 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 [this message]
2010-05-05 22:22 ` Michael Snyder
2010-05-05 22:39 ` Pedro Alves
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=201005052241.14753.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