From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 873 invoked by alias); 11 Dec 2008 23:28:29 -0000 Received: (qmail 863 invoked by uid 22791); 11 Dec 2008 23:28:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Dec 2008 23:27:54 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBBNPq5C021089; Thu, 11 Dec 2008 18:25:52 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBBNPoh9014790; Thu, 11 Dec 2008 18:25:51 -0500 Received: from opsy.redhat.com (vpn-12-219.rdu.redhat.com [10.11.12.219]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBBNPn0W012506; Thu, 11 Dec 2008 18:25:50 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id F1B33508027; Thu, 11 Dec 2008 16:25:48 -0700 (MST) To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFA: fix macro expansion bug References: <200812112304.39302.pedro@codesourcery.com> From: Tom Tromey Reply-To: Tom Tromey Date: Thu, 11 Dec 2008 23:28:00 -0000 In-Reply-To: <200812112304.39302.pedro@codesourcery.com> (Pedro Alves's message of "Thu\, 11 Dec 2008 23\:04\:38 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00214.txt.bz2 >>>>> "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? >> + "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. Tom 2008-12-11 Tom Tromey * macroexp.c (get_pp_number): Require digit after leading ".". Correctly handle suffixes. 2008-12-11 Tom Tromey * gdb.base/macscp.exp: New regression test. diff --git a/gdb/macroexp.c b/gdb/macroexp.c index 7fb23ce..dda3592 100644 --- a/gdb/macroexp.c +++ b/gdb/macroexp.c @@ -278,20 +278,22 @@ get_pp_number (struct macro_buffer *tok, char *p, char *end) { if (p < end && (macro_is_digit (*p) - || *p == '.')) + || (*p == '.' + && p + 2 <= end + && macro_is_digit (p[1])))) { char *tok_start = p; while (p < end) { - if (macro_is_digit (*p) - || macro_is_identifier_nondigit (*p) - || *p == '.') - p++; - else if (p + 2 <= end - && strchr ("eEpP.", *p) - && (p[1] == '+' || p[1] == '-')) + if (p + 2 <= end + && strchr ("eEpP", *p) + && (p[1] == '+' || p[1] == '-')) p += 2; + else if (macro_is_digit (*p) + || macro_is_identifier_nondigit (*p) + || *p == '.') + p++; else break; } diff --git a/gdb/testsuite/gdb.base/macscp.exp b/gdb/testsuite/gdb.base/macscp.exp index 9cb9ef5..40021b9 100644 --- a/gdb/testsuite/gdb.base/macscp.exp +++ b/gdb/testsuite/gdb.base/macscp.exp @@ -652,3 +652,11 @@ gdb_test "print str(maude)" \ gdb_test "print xstr(maude)" \ " = \"5\"" \ "stringify with substitution" + +# Regression test for pp-number bug. +gdb_test "macro define si_addr fields.fault.si_addr" \ + "" \ + "define si_addr macro" +gdb_test "macro expand siginfo.si_addr" \ + "expands to: siginfo. fields.fault.si_addr" \ + "macro expand siginfo.si_addr"