From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11887 invoked by alias); 19 Mar 2002 03:51:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11784 invoked from network); 19 Mar 2002 03:51:39 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 19 Mar 2002 03:51:39 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 694795E9DE; Mon, 18 Mar 2002 22:51:38 -0500 (EST) To: Neil Booth Cc: gdb-patches@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: C/C++ preprocessor macro support for GDB References: <20020317062306.CC96D5E9DE@zwingli.cygnus.com> <20020318183339.GB19897@daikokuya.demon.co.uk> From: Jim Blandy Date: Mon, 18 Mar 2002 19:51:00 -0000 In-Reply-To: <20020318183339.GB19897@daikokuya.demon.co.uk> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00337.txt.bz2 Neil Booth writes: > I've looked over your patch a little more, and I don't think your macro > expander works, because it doesn't mark individual tokens. A "disabled > macro" stack is *not* enough by itself to implement ISO C macro expansion > semantics. You need to attach information to individual tokens as well. > I've not tried it, but I'd bet that > > #define A(x) x A(A)(1) > > expands to "1" with your code, whereas the correct expansion is "A(1)". > Implementing this properly is a PITA, more so with a text-based expander > like yours. It would be very hard to get the same (correct) semantics as > cpplib in corner cases with a text-based expander (2.95 has outstanding > bugs in this area). Just for the record: (gdb) show macro A Defined at /home/jimb/gdb/macros/play/test.c:12 #define A(x) x (gdb) macro expand A(A)(1) expands to: A(1) (gdb) That's not to say that there aren't other subtle bugs in there. :) And that's also not to say that replacing my macroexp.c with libcpp isn't the right thing to do.