From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9460 invoked by alias); 11 Dec 2008 23:35:49 -0000 Received: (qmail 9447 invoked by uid 22791); 11 Dec 2008 23:35:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Dec 2008 23:35:14 +0000 Received: (qmail 17711 invoked from network); 11 Dec 2008 23:35:11 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Dec 2008 23:35:11 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFA: fix macro expansion bug Date: Thu, 11 Dec 2008 23:35:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <200812112304.39302.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812112335.15980.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00216.txt.bz2 On Thursday 11 December 2008 23:25:48, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > > Pedro> Though, I'm having a bit of trouble convincing myself that the logic to > Pedro> handle 'pp-number e|E|p|P|. sign' below is 100% sane. > [...] > Pedro> It seems macro_is_identifier_nondigit will always eat any of "eEpP", > Pedro> thus, say, when parsing "1e-" only "1e" will be identified as a pp > Pedro> number, leaving "+" in the stream. Is this right? > > Yeah. Also, "." should not appear in the strchr argument. > > Here's a new patch. I'll regression-test it. I don't expect > problems. Ok if it passes? Certainly. Thanks. > >> + "expands to: siginfo. fields.fault.si_addr" \ > > Pedro> Just curious, as it's just a visual annoyance: do you know where > Pedro> this space comes from? Do we store the definition with the space for > Pedro> some reason? We don't get that extra space if the define came > Pedro> from the code, instead of from a 'macro define'. > > Yes, it is a bug in "macro define". > I'll fix shortly. > Thanks! -- Pedro Alves