From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19180 invoked by alias); 29 Mar 2002 21:27:09 -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 19173 invoked from network); 29 Mar 2002 21:27:07 -0000 Received: from unknown (HELO monkey.daikokuya.demon.co.uk) (158.152.184.26) by sources.redhat.com with SMTP; 29 Mar 2002 21:27:07 -0000 Received: from neil by monkey.daikokuya.demon.co.uk with local (Exim 3.35 #1 (Debian)) id 16r3ty-0002KO-00; Fri, 29 Mar 2002 21:27:14 +0000 Date: Fri, 29 Mar 2002 13:27:00 -0000 From: Neil Booth To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: preprocessor macro support (should actually work now) Message-ID: <20020329212714.GA8915@daikokuya.demon.co.uk> References: <20020328070504.24F455EA11@zwingli.cygnus.com> <20020329100102.GA1261@daikokuya.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-SW-Source: 2002-03/txt/msg00610.txt.bz2 Jim Blandy wrote:- > For spectators: libcpp represents the stream of source code it's > expanding as an array of token structures, not a simple array of > characters. When it sees some macro named X expand to a sequence that > includes the identifier token X, it sets a flag on that token > indicating that it should never be expanded as a macro invocation. As > the example shows, this flag may need to remain set long after the > original invocation of the macro named X has been processed. I don't > see any easy way to get this effect with a string-based expander, like > the one in my patch. Yah, it's a mess. Have you looked at the venerable "cccp" that was the expander for 2.95.x and earlier? It's a right kludge; but it works in most cases (still a few bugs, and segfaults). It "surrounds" such tokens with "\r" in its buffer, to indicate the token should not be expanded. It worked, but it was a little tasteless IMO 8^) > I didn't really understand all the logistics that got brought up > regarding moving libcpp into its own directory in the repository, to > make it easier to share with gdb. But the sooner that happens, the > sooner we can replace my macro expander with one that works better. Best left to Zack. I don't think I'm qualified 8-) Neil.