Re: [Nasm-devel] [nasm:master] BR30730640: Restore preprocessor token concatenation rules

[Cyrill G. <gor...@gm...>]

On Fri, Oct 01, 2010 at 12:09:00PM +0200, anonymous coward wrote:
> >> > The former candidates for concatenation were (in terms of RE)
> >> >
> >> > expand_smacro
> >> >    [(TOK_ID|TOK_PREPROC_ID)][(TOK_ID|TOK_PREPROC_ID|TOK_NUMBER)]
> >> >
> >> > expand_mmac_params
> >> >    [(TOK_ID|TOK_NUMBER|TOK_FLOAT)][(TOK_ID|TOK_NUMBER|TOK_FLOAT|TOK_OTHER)]
> >>
> >> The above permit concatenations that result in invalid
> >> tokens, and therefore need to be tightened. Try these
> >> rules instead:
> >>
> >> - whitespace(s)/tab(s) with whitespace(s)/tab(s)
> >> - identifiers with either identifiers or numbers or $/$$
> >> - preprocessor identifiers or numbers with numbers
> >> - $ with identifiers or numbers that don't begin with $
> >>
> >> I don't know enough about TOK_FLOAT to comment.
> >
> > OK, thanks for comments, I'll take a look tomorrow. But basically I would
> > rather like to hear which exactly invalid tokens you mean? Mind
> > to elaborate if you have some spare minutes? Also I fear this part of
> 
> In your first set of rules you cannot have TOK_PREPROC_ID on
> the right side, since it may start with a character that cannot be
> inside a TOK_ID or TOK_NUMBER.
>

We still have to support it since people use it

%assign %$_uses 0
%rep 4
	%assign %$_ur%$_uses %$_uses
	mov eax, %$_ur%$_uses
	%assign %$_uses %$_uses+1
%endrep

and friends, we just can't drop it.

> 
> In your second set of rules you cannot have TOK_NUMBER plus
> TOK_ID, let alone xxx plus any TOK_OTHER, for the same basic
> reason as above.
>

Well, as far as I see there can't be a combination of TOK_NUM+TOK_ID
as a single term to be concat'ed, it's written this way in mask
due to simplicity of handling.

So at moment I fail to see what exactly may produce wrong concat'ed
terms. Please, if you have a real example with code -- poke me, thanks.

Cyrill