This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: macro expansion and operator &&


On Mon, Aug 16, 2010 at 09:38:48AM +0100, Jan Beulich wrote:
> >>> On 16.08.10 at 07:01, Alan Modra <amodra@gmail.com> wrote:
> > --- gas/macro.c	23 Jul 2010 06:44:25 -0000	1.53
> > +++ gas/macro.c	16 Aug 2010 04:53:52 -0000
> > @@ -748,6 +748,8 @@ sub_actual (int start, sb *in, sb *t, st
> >        /* Doing this permits people to use & in macro bodies.  */
> >        sb_add_char (out, '&');
> >        sb_add_sb (out, t);
> > +      if (src != start && in->ptr[src - 1] == '&')
> > +	sb_add_char (out, '&');
> >      }
> >    else if (copyifnotthere)
> >      {
> 
> While I didn't verify it, I would think that in alternate macro mode
> you shouldn't put back the ampersand.

I think we should, even in alternate mode.  Otherwise you can't have
an expression like x&y&z where none of x,y,z are macro parameters.
Without the patch, you'd get x&yz.  I guess I'm saying that if we want
to be able to use '&' and '&&' as operators, then we need to change
the rules for '&' as a separator in alternate mode.

> Actually, according to the
> comment around the respective invocation of sub_actual(), I have
> always been suspecting that the function should only be called
> there in alternate mode anyway.

That was the first thing I tried when looking into this problem.
gas/all/altmacro fails.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]