This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch][python] Add breakpoint support.
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches ml <gdb-patches at sourceware dot org>, Eli Zaretskii <eliz at gnu dot org>
- Date: Wed, 07 Apr 2010 15:09:12 -0600
- Subject: Re: [patch][python] Add breakpoint support.
- References: <4BB0B063.6000600@redhat.com> <20100405162648.GD19194@adacore.com> <4BBB3AF6.8050407@redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "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