From: Tom Tromey <tromey@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Cleanups and Exception handlers
Date: Mon, 06 May 2013 17:32:00 -0000 [thread overview]
Message-ID: <87sj20ypyk.fsf@fleche.redhat.com> (raw)
In-Reply-To: <5180EE37.3020507@redhat.com> (Phil Muldoon's message of "Wed, 01 May 2013 11:28:07 +0100")
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Phil> I'd like to quantify and discuss strategies of cleanups and GDB exception
Phil> handlers. It seems I am always making mistakes in this area, and the
Phil> comments in the TRY_CATCH macro (well to me) are not adequate about the
Phil> mechanics of cleanups in an exception handler.
Phil> So I would like to discuss patterns of usage with a view to updating
Phil> the comments to be more explanatory.
There's also a section in gdbint.texinfo, though it seems reasonably out
of date, seeing as it does not mention TRY_CATCH at all.
The simplest, and IMO therefore best, way to approach cleanups is to
pretend that they introduce blocks.
That is, when you see an assignment of a cleanup to a local:
cleanup = make_cleanup (...);
you should mentally add a "{" to the text.
And when you see a do_cleanups or discard_cleanups call, you should
mentally add a "}".
Then, if the braces in the function -- all of them, the real ones plus
the one you added mentally -- do not balance, something is wrong.
This approach is sufficient for most of the code in gdb. There are some
necessary exceptions to the rule (some functions must return cleanups
somehow; and also sometimes the strict lexical rule will not work), some
weird code, and some code making assumptions about its caller. The
cleanup checker (archer.git tromey/cleanup-checker) diagnoses these.
It is of course possible to be more dynamic with cleanups and not to
pretend they are block structured. There aren't any actual rules.
However, I think the more dynamic style is bug-prone, and my proof of
this is the large number of actual bugs in this area that I've fixed
over the years, including all the ones fixed on the cleanup-checker
branch but not yet submitted.
Tom
prev parent reply other threads:[~2013-05-06 17:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-01 10:28 Phil Muldoon
2013-05-01 15:21 ` Jan Kratochvil
2013-05-01 18:46 ` Phil Muldoon
2013-05-01 19:44 ` Jan Kratochvil
2013-05-04 17:52 ` Doug Evans
2013-05-06 17:32 ` Tom Tromey [this message]
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=87sj20ypyk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb@sourceware.org \
--cc=pmuldoon@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