From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13324 invoked by alias); 20 Sep 2008 15:19:40 -0000 Received: (qmail 13316 invoked by uid 22791); 20 Sep 2008 15:19:39 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 20 Sep 2008 15:19:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D668F2A96C6; Sat, 20 Sep 2008 11:19:02 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IH4x8mPCgqVR; Sat, 20 Sep 2008 11:19:02 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 67D052A96A7; Sat, 20 Sep 2008 11:19:02 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id C703EE7ACD; Sat, 20 Sep 2008 08:18:59 -0700 (PDT) Date: Sat, 20 Sep 2008 15:19:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFA: implement all missing macro expansion features Message-ID: <20080920151859.GD23372@adacore.com> References: <20080920001852.GC23372@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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-09/txt/msg00441.txt.bz2 > Joel> Thanks for adding the comment describing the function. Can you add an > Joel> extra empty line before the function declaration? > > Sure. I was not sure which style is the preferred one -- though I see > now that this is in gdbint.texinfo. That said, both styles are common > in gdb, and in macroexp.c in particular, the blank line only appears > in one case. Yes, that's true. I am not too fussy about this as it doesn't make a whole lot of difference to me. But I try to correct them when I see them. > >> + /* Just ignore a stray token splicing operator. Really this > >> + is an error, but there's no reason to penalize the > >> + user. */ > > Joel> I don't see how this would be penalizing the user. when could > Joel> this error actually happen? > > Some versions of gcc will pass a macro like this through. > Trunk rejects code that tries to do this. By 'this' I mean error > cases like having '##' at the start or end of the macro definition. > > So, it can only happen in very weird circumstances. > > I can make it an error. I doubt anybody will notice. > I'll resubmit the patch a bit later. I will let you decide what makes the most sense. If you think that it makes better sense to accept it, then I'll go with that. GNU tools in general try to be very open in what they accept so your approach is reasonable. Perhaps a warning explaining that the splicing operator has been ignored? (just some thoughts) -- Joel