[Nasm-devel] [Bug 3392716] Macro expansion behaviour

[Igor Munkin]

Cyrill,

On 10.12.20, Cyrill Gorcunov wrote:
> On Thu, Dec 10, 2020 at 01:10:20AM -0800, hpa at zytor.com wrote:

<snipped>

> > 
> > Hi,
> > 
> > I think we're should simply disallow undefining or redefining a macro that
> > is in the process of being expanded. We have that information as we tag all
> > the macros we have descended through.
> 
> You know, I think defer cleanup would be a way more powerful -- see the perl
> example above. The ability to undefine macros during expansion allows to make
> them oneshot.

I think it's not about power, but the consistency and common sense.
Since there is no a single word regarding the case in docs now, this is
a gray zone and we need to design the solution to be the most consistent
one (IMHO).

I have no idea how often such insane construction is used. AFAIU it
already works as "oneshot" now, but with UAF while expansion and *this
has to be fixed*. Peter suggested to make it nop, so it would never be
undefined within its expantion and ergo it would not be "oneshot"
anymore. As a result original semantics looks to be broken, but since
it's not described, we can make it work the way we want (omitting such
aspects as backward compatibility).

> 
> Though to be honeset I didn't dive into code details yet and not sure how
> much effort if might require to implement, so maybe indeed simply disallow
> undef/redef during expansion is the only way for now...

I personally prefer the deferred %unmacro, but totally share your
concerns regarding this solution in scope of the current implementation.

I guess I'll try both ways since I believe we can't estimate the amount
of changes to be done without attempting to implement at least PoC for
yours proposal.

NB: I have no idea how redefinition works in this case, but it looks
also hits the problem.

> 

<snipped>

-- 
Best regards,
IM