From: Tom Tromey <tromey@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
gdb-patches ml <gdb-patches@sourceware.org>,
Eli Zaretskii <eliz@gnu.org>
Subject: Re: [patch][python] Add breakpoint support.
Date: Wed, 07 Apr 2010 21:09:00 -0000 [thread overview]
Message-ID: <m3ochvt1fr.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4BBB3AF6.8050407@redhat.com> (Phil Muldoon's message of "Tue, 06 Apr 2010 14:45:26 +0100")
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Joel> This is definitely the standard, currently. Is that normal?
Phil> In the archer repository some are and some aren't (for whatever
Phil> reason).
Yeah, we probably just missed them.
Joel> Personally (and I litterally mean it, it's a personal preference),
Joel> I'd rather we did not use macros, but a real function... Being a static
Joel> function, I'm sure the compiler will be capable of performing whatever
Joel> is best for performance (and that way, we can avoid the parens around
Joel> "Num", and the "do/while(0)" dance in the macro that follows).
Phil> The use of macros to check consistency of various GDB objects in the
Phil> Python API seems pretty consistent with the code that is already in
Phil> FSF CVS, and the code that is still in the Archer GIT repository . As
Phil> a lot of this code is an effort from several different people over
Phil> several periods of time, I cannot answer why this trend became the
Phil> default.
Things like GDB_PY_HANDLE_EXCEPTION have a "return" built in, which is
why they must be macros.
In this code I think it would be ok to replace BPPY_VALID_P with an
appropriately-named static function. However, BPPY_REQUIRE_VALID and
BPPY_SET_REQUIRE_VALID still have to be macros. (Well... you could make
them functions and do an extra check in the caller, but as you say this
style is already prevalent in the python code.)
Tom
next prev parent reply other threads:[~2010-04-07 21:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 13:52 Phil Muldoon
2010-03-29 14:28 ` Eli Zaretskii
2010-03-29 14:53 ` Phil Muldoon
2010-03-29 15:15 ` Eli Zaretskii
2010-04-05 16:27 ` Joel Brobecker
2010-04-06 13:47 ` Phil Muldoon
2010-04-06 18:21 ` Eli Zaretskii
2010-04-07 21:09 ` Tom Tromey [this message]
2010-04-08 12:42 ` Phil Muldoon
2010-04-08 15:29 ` Joel Brobecker
2010-04-08 19:48 ` Phil Muldoon
2010-04-08 20:41 ` Tom Tromey
2010-04-08 21:27 ` Phil Muldoon
2010-04-08 21:45 ` Joel Brobecker
2010-04-08 22:21 ` Pedro Alves
2010-04-08 23:26 ` Joel Brobecker
2010-04-08 23:40 ` Pedro Alves
2010-04-09 15:35 ` Tom Tromey
2010-04-09 15:32 ` Tom Tromey
2010-04-08 19:57 ` Tom Tromey
2010-04-09 10:11 ` Phil Muldoon
2010-04-07 21:19 ` Joel Brobecker
2010-06-11 17:41 ` Ulrich Weigand
2010-06-11 20:28 ` Phil Muldoon
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=m3ochvt1fr.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@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