From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10675 invoked by alias); 9 Feb 2005 10:12:18 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 10470 invoked from network); 9 Feb 2005 10:12:07 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 9 Feb 2005 10:12:07 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Wed, 09 Feb 2005 10:12:07 +0100 Message-Id: Date: Wed, 09 Feb 2005 14:32:00 -0000 From: "Jan Beulich" To: Cc: Subject: Re: [PATCH] Re: .macro behavior Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2005-02/txt/msg00154.txt.bz2 >I don't see what's wrong with that. I'd say it actually >simplifies macro definitions and usage. The macro parameter >name is used only in a macro definition, as a placeholder. It's >no big limitation to make it alphanumeric_ only. Otherwise, the >macro writer that wants to cater to multiple GAS ports (say, in >a package similar to glibc) would have to avoid making the >parameter name followed by any non-space character at all, in >case some port has that character as part of an identifier. The change doesn't prevent anyone from continuing to only use alphanumeric characters for macro parameter names. And such a name can validly only be followed by a comma or equal sign (perhaps whitespace, but no other punctuation), so allowing more characters for use in parameter names can't break anything (at least no properly written code), unless a port allows '=' in symbol names (those, the existence of which I question, would have to separate parameter name and = by whitespace). Jan