#128 late %$id to ..@<number>.id conversion can be problematic


One of the SciTech changes was to delay the
conversion of %$id to ..@<number>.id until
after multi-line macros have been expanded,
instead of performing it at the end of each
call to the expand_smacro() function.

The change was made to allow code like this:

%macro mmac 1
%define %1 nop

%push c
mmac %$abc
; old: "..@<n>.abc" (orphan label warning)
; new: "nop" (valid instruction)

However, as pointed out by Zlatko Karakas,
the change does break the following code:

%push c
%assign %$a 1
%if %$a == 1
%$l: equ 1
%if %$l == 1
; old: "..@<n>.l == 1" (true)
; new: "%$l == 1" (expression syntax error)

Because both the old and the new behavior
do seem useful, the user should be able to
select between the two, e.g. by means of a
preprocessor directive. (I've got a working
in my local forked version. It's also used
for EXPAND=[NO|YES] (see SF #644619), and
LOOKUP=[ONE|ALL] (outer context lookups).
And of course it's accompanied by a set of
that allow the user to query the state.)


  • nasm64developer

    nasm64developer - 2003-10-02
    • priority: 5 --> 1
    • status: open --> open-works-for-me
  • Nickolay Yurchenko

    • labels: --> Preprocessor Bugs
    • assigned_to: nobody --> unv
  • Nickolay Yurchenko

    Logged In: YES

    No, this bug appears because ppscan() does not convert
    TOK_PREPROC_ID %$<name> into ..@<num>.<name>. This
    is quite simple to fix.

    By the way, detoken() now behaves like expand-function. For
    example, it expands %!<name> (the only way this 'feature'
    works is because detoken is called first for making listing) and
    it can convert context-local macro names (not only in the
    result string, but names of macros in source token list). So,
    detoken() may return token list different from given into it.
    This is quite wrong, I think.

  • nasm64developer

    nasm64developer - 2003-11-01

    Logged In: YES

    I have come up with an even better solution: use
    the proposed %# functionality -- see SF #829879.


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks