From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8699 invoked by alias); 9 Feb 2005 08:17:52 -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 8074 invoked from network); 9 Feb 2005 08:16:25 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 9 Feb 2005 08:16:25 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Wed, 09 Feb 2005 08:16:24 +0100 Message-Id: Date: Wed, 09 Feb 2005 10:28: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/msg00148.txt.bz2 >>> Hans-Peter Nilsson 08.02.05 18:31:37 >>> >On Tue, 8 Feb 2005, Jan Beulich wrote: > >> >> >> only allows [[:alpha:]_$][[:alnum:]_$]* >> > >> >I think this restriction is actually good. Calls for the least >> >amount of surprises when applying the same macro to different >> >GAS ports. >> >> Not so. If, on IA-64 as an example, I want to define an >> instruction-like macro, I need to have '.' as an acceptable character >> for the macro name. > >I thought you were talking about macro *parameter names*, as >that's the change that exposed the mistake in the MMIX >test-case. I agree the macro names themselves should be >freely chosen (anything but whitespace or whatever). I'm actualy talking about both, and since both are symbol names, both should get the same treatment as ordinary symbols (despite agreeing that for macro parameters the previous restriction is less hurting). Otherwise it's just inconsistent. Jan