From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25593 invoked by alias); 9 Feb 2005 10:28:44 -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 25537 invoked from network); 9 Feb 2005 10:28:33 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sourceware.org with SMTP; 9 Feb 2005 10:28:33 -0000 Received: (qmail 11805 invoked by uid 20157); 9 Feb 2005 10:28:32 -0000 Date: Wed, 09 Feb 2005 15:03:00 -0000 From: Hans-Peter Nilsson X-X-Sender: hp@dair.pair.com To: Jan Beulich cc: binutils@sources.redhat.com Subject: Re: [PATCH] Re: .macro behavior In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-02/txt/msg00155.txt.bz2 On Wed, 9 Feb 2005, Jan Beulich wrote: > >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), You are referring to the ".macro ..." line, right? You don't really mean within the macro, where the parameter name is *used* right? *Within* a macro definition, it can be followed by e.g. a ":", and the sematics is now changed. If you're actually making an (artificial) restriction on a macro parameter name use within a macro definition above, then that should be documented. > 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). Well, something broke... It doesn't take much imagination to go from the breaking \x: in the mmix test-case to e.g. a macro with a \x*2 in the macro body and a target with "*" in the symbol character set. Or "+", or... You changed behavior of macro (names, parameters), so I think it's only prudent to document the change even (certainly a gas/NEWS item) if only vaguely saying that an artificial restriction on symbols in macro names and parameters has been lifted. brgds, H-P