From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21944 invoked by alias); 23 Jan 2006 22:46:50 -0000 Received: (qmail 21936 invoked by uid 22791); 23 Jan 2006 22:46:50 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.200) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jan 2006 22:46:47 +0000 Received: by zproxy.gmail.com with SMTP id x3so1012771nzd for ; Mon, 23 Jan 2006 14:46:45 -0800 (PST) Received: by 10.36.251.60 with SMTP id y60mr1284869nzh; Mon, 23 Jan 2006 14:46:45 -0800 (PST) Received: by 10.37.2.42 with HTTP; Mon, 23 Jan 2006 14:46:45 -0800 (PST) Message-ID: <8f2776cb0601231446j3f962793ic4669b0b1aa5cecc@mail.gmail.com> Date: Mon, 23 Jan 2006 22:46:00 -0000 From: Jim Blandy To: gdb-patches@sourceware.org, Andrew STUBBS , Jim Blandy Subject: Re: [RFC] Alternate approach to keeping convenience variables In-Reply-To: <20060122213118.GH27224@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> <20060122213118.GH27224@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00344.txt.bz2 On 1/22/06, Daniel Jacobowitz 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.