From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14994 invoked by alias); 2 Mar 2005 14:42:12 -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 14887 invoked from network); 2 Mar 2005 14:42:00 -0000 Received: from unknown (205.217.158.180) by sourceware.org with QMTP; 2 Mar 2005 14:42:00 -0000 Received: (qmail 4710 invoked by uid 10); 2 Mar 2005 14:41:59 -0000 Received: (qmail 7443 invoked by uid 500); 2 Mar 2005 14:41:51 -0000 Mail-Followup-To: binutils@sources.redhat.com, JBeulich@novell.com To: "Jan Beulich" Cc: Subject: Re: [PATCH] Re: .macro behavior References: From: Ian Lance Taylor Date: Wed, 02 Mar 2005 14:42:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-03/txt/msg00071.txt.bz2 "Jan Beulich" writes: > >And I still think there's greater benefit from keeping the > >syntax of macro *parameter names* the same as today, something > >like "[A-Za-z_][A-Za-z0-9_]+" and not dependent on the target > >symbol character set. (Heh, saying :alpha: and :alnum: would > >imply it's locale-dependent. I don't think we want *that*! ;-) > > One additional note here: The current behavior is to allow > "[A-Za-z_$][A-Za-z0-9_$]+", which already is in conflict with some > targets' use of '$' (see those defining LEX_DOLLAR). > I would consider it acceptable to shrink the set down to > "[A-Za-z_][A-Za-z0-9_]+" as you suggest (in order to be largest commonly > acceptable set in general. However, since macros can be used to define > macros, having a way to avoid 'common' symbol names may be quite > valuable, and having available as option here only underscores (to add a > prefix and/or suffix) may make things rather difficult. I'd therefore > like to not restrict targets that allow a reasonable set of additional > symbol characters from actually using them here. > > Still, I'm hoping to get comments on this from others, namely Ian, who > originally agreed that the current behavior doesn't seem to be > intended. I'm reading this, but I don't have any particular comment. The current behaviour was an accident of implementation. I think Steve and Judy wrote gasp over a weekend once, and I didn't change the behaviour when I reworked it into gas. But I don't really have an opinion on what the right behaviour should be. Ian