#179 Document (and possibly improve) %unmacro on executing macro

open
nobody
5
2010-10-16
2010-10-16
C. Masloch
No

Using %unmacro on a macro that currently executes appears to work fine, but I expect that it might cause NASM to segfault in some cases. A %warning inside such a non-existing macro (ie. behind the %unmacro that removed this macro) will display an empty string for the current macro's name. (Both tested with NASM 2.10rc1, Win32.) The request concerns documenting the current behaviour (ie. that it is allowed to use %unmacro for a currently executing macro), and if necessary improving NASM's behaviour so that it will not segfault in this situation; or additionally improving NASM's behaviour here in other ways.

Discussion

  • nasm64developer

    nasm64developer - 2010-10-18

    The current implementation of %UN(I)MACRO is actually broken
    because it unconditionally frees the mmac even if in_progress is
    true. The proper solution is to introduce a new mmac field which
    defers the free until the mmac is done i.e. in_progress goes false.

     
  • H. Peter Anvin

    H. Peter Anvin - 2010-10-18

    The proper thing is to have a reference count which counts the sum of the number of namespace bindings and the number of pending invocations. This should also make it practical to unify the code related to %rep (and eventually other block constructs) since those then simply become mmacros that are not bound to any namespace.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks