This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Alternate approach to keeping convenience variables
- From: Jim Blandy <jimb at red-bean dot com>
- To: gdb-patches at sourceware dot org, Andrew STUBBS <andrew dot stubbs at st dot com>, Jim Blandy <jimb at red-bean dot com>
- Date: Mon, 23 Jan 2006 14:46:45 -0800
- Subject: Re: [RFC] Alternate approach to keeping convenience variables
- References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> <20060122213118.GH27224@nevyn.them.org>
On 1/22/06, Daniel Jacobowitz <drow@false.org> wrote:
> This version of the patch addresses all the comments I've received,
> except for:
>
> - TYPE_ZALLOC. I think this is more appropriate as a macro,
> personally, though I wouldn't argue too loudly if someone wanted to
> functionify it at the same time as TYPE_ALLOC.
That's fine. I'll have to put my typing where my mouth is.
> GDB developers seem to have developed an allergy to C macros that
> I just don't understand. They're not _inherently_ obfuscating
> or evil! They can be both useful and elegant.
Nobody commented on my creative use of macros in m32c-tdep.c. If I
were allergic, that'd definitely put me in anaphylactic shock.
I don't like TYPE_ZALLOC and TYPE_ALLOC because they don't get
anything special from being macros. These aren't time-critical bits
of code. They don't construct names. They don't take a type as an
argument (err, a compile-time type, that is). They don't expand to
statements. They don't export an interface whose presence you'd like
to be able to test for easily at compile-time. So why not get the
nicer syntax, type checking, and debuggability that functions provide?
De gustibus non est disputandum.