[PATCH] Re: .macro behavior

[Hans-Peter Nilsson]

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