From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13028 invoked by alias); 8 Feb 2005 17:31:42 -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 13013 invoked from network); 8 Feb 2005 17:31:38 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sourceware.org with SMTP; 8 Feb 2005 17:31:38 -0000 Received: (qmail 98884 invoked by uid 20157); 8 Feb 2005 17:31:37 -0000 Date: Tue, 08 Feb 2005 23:05: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/msg00133.txt.bz2 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). brgds, H-P