From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23088 invoked by alias); 20 Apr 2005 09:34:33 -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 23075 invoked from network); 20 Apr 2005 09:34:30 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sourceware.org with SMTP; 20 Apr 2005 09:34:30 -0000 Received: (qmail 68859 invoked by uid 20157); 20 Apr 2005 09:34:30 -0000 Date: Wed, 20 Apr 2005 09:34:00 -0000 From: Hans-Peter Nilsson X-X-Sender: hp@dair.pair.com To: Jan Beulich cc: binutils@sources.redhat.com Subject: Re: macro behavior In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-04/txt/msg00548.txt.bz2 On Wed, 20 Apr 2005, Jan Beulich wrote: > .macro gproc name:req, more:vararg > .global \name > .type \name, @proc > .ifnb \more > gproc \more > .endif > .endm > > These qualifiers mean > > req argument value required > vararg parameter covers all remaining arguments, if any > > while by default specifying an argument value would remain > optional (including the use of = to specify a default > value). Of course, the use of : here again may present some > issues, since MMIX allows : in symbol names, but other than > above I think this could be tolerated, just requiring to use > white space around the colon to disambiguate things. Whitespace separates parameters, not just comma, so I don't think that'd be disambiguating. I stand by my position that allowing other than alphanumerics + _ in macro parameter names is a walk down the wrong lane. The powerpc symbol issue seems to support that position. (BTW, I agree with davem that your overlong lines makes communication harder.) brgds, H-P