Menu

#112 Figure brackets enclosure

open-works-for-me
1
2004-02-15
2003-08-23
No

Multiline macro expander doesn't handle square brackets
enclosure:

%define foo1(x) x

%macro foo2 1-*
%error %1
%endm

%error foo1( {1, {2}, 3} ) ; result: 1, {2}, 3
foo2 {1, {2}, 3} ; result: 1, {2

This is bug, I suppose, and I'll fix it.
Current behaviour doesn't allow some interesting syntax,
like hierachical structure initialization:

;foo structure definition:
;foo.a, foo.b, foo.bar.a, foo.bar.b, foo.c

initstruc foo, {v1, v2, {v3, v4}, v5}

Discussion

  • Nickolay Yurchenko

    • labels: --> Preprocessor Bugs
    • assigned_to: nobody --> unv
     
  • nasm64developer

    nasm64developer - 2003-08-23

    Logged In: YES
    user_id=804543

    Yeah, preproc.c's count_mmac_params() and expand_mmacro()
    functions don't count opening/closing curly braces, like
    the expand_smacro() function does. Which is why -- as of
    writing this -- one can't pass "{.+}" as an argument to
    a multi-line macro, i.e. a closing curly brace.

     
  • nasm64developer

    nasm64developer - 2003-09-10

    Logged In: YES
    user_id=804543

    As noted by Nickolay, a comma between the arguments of
    a single-line macro invocation didn't act like a "}",
    and thus lead to incorrect argument treatment. The fix
    is to set brackets to 0 just after the 2nd of the three
    occurences of "white = 0;" in preproc.c.

    With that bug out of the way, I'll look at multi-line
    macro arguments and curly braces next.

     
  • Nickolay Yurchenko

    Logged In: YES
    user_id=806493

    I've redesigned a bit multiline macro expansion - now only
    count_mmac_params() counts and demarcates parameters.
    And does it correctly. I've also renamed is_mmacro() to
    get_mmacro(), which returns full-formed multiline macro
    reference with filled parameters array (this is not in CVS yey,
    of course - it's for Nasm 0.99).

     
  • nasm64developer

    nasm64developer - 2003-09-10

    Logged In: YES
    user_id=804543

    Since Nickolay's re-write of preproc.c isn't likely
    to be accepted until it has been (a) spec'd/approved
    and (b) thoroughly verified by a substantial number
    of users and developers, I have started to work on a
    fix for the existing preproc.c, that can be used in
    the meantime.

    I think that I've got it, but I want to do some more
    testing first.

    So stay tuned...

     
  • nasm64developer

    nasm64developer - 2003-09-11

    Logged In: YES
    user_id=804543

    I've got everything to work, except for one case.

    How does one pass the opening curly brace '{' as
    an argument to a single-line macro?

    In case of a multi-line macro it can be done, as
    long as it is the last argument.

    However, in case of a single-line macro there has
    to be a closing parenthesis. Which, if preceded by
    an opening curly brace, just becomes part of that
    last (literal) argument and thus causes an error
    due to a missing closing parenthesis.

    All those curly braces made my head hurt... 8-)

    Let me know if you're interested in my testcases.

     
  • nasm64developer

    nasm64developer - 2003-09-12

    Logged In: YES
    user_id=804543

    I have found the answer to my question.

    Since single-line macro arguments are counted before
    they are expanded, the opening curly brace '{' can be
    passed as a single-line macro argument by "wrapping"
    it in another single-line macro, like so:

    %define oc {
    %define smac(x) x
    %error [smac(oc)] ; filename.asm:3: warning: [{]

    Btw, the same trick won't work for multi-line macro
    arguments, because single-line macros are expanded
    before multi-line macros are. That is, a multi-line
    macro would see '{' instead of 'oc'.

    However, with my upcoming fixes one can pass '{{'
    as the last argument of a multi-line macro -- this
    will result in '{'.

    That said, I'm in the process of wrapping up those
    fixes; I'll post them shortly. As well as all the
    testcases I've come up with.

     
  • nasm64developer

    nasm64developer - 2003-09-12

    Logged In: YES
    user_id=804543

    I've posted my changes and testcases to the nasm-devel
    list, since I can't seem to attach them here.

     
  • Nickolay Yurchenko

    Logged In: YES
    user_id=806493

    I don't think we should use such hacks for '{' itself. This is a
    control token anyway. And it should have a pair - otherwise
    error must be given. If we want to use it as usual token we
    should add escape syntax (like \{ ). But I think if someone
    wants to pass safely complex token list into a multiline macro
    he can use following syntax:

    %define oc {
    %define smac(x) x
    foo %detok(smac(x)) ; foo "{"

    where foo is:

    %macro foo 1
    %xdefine param1 %strtok(%1)
    ...
    %endm

    We'll get the expected result.

    And one even may pass something monsterous in this way:
    foo "{(,{)[]"

     
  • nasm64developer

    nasm64developer - 2003-09-12

    Logged In: YES
    user_id=804543

    Yes, normally curly braces should be used in pairs and
    the outer-most pair should enclose an entire parameter.

    However, there are occasions when I need to pass single
    opening or closing curly braces to a single- or multi-
    line macro. For example, during my debug output macros.

    I did consider adding support for a more generic escape
    mechanism a la backslash (and in fact had to do so for
    the primitive assembler directives, to be able to use a
    closing square bracket in an argument), but shied away
    from attempting such an intrusive overall change, which
    would have rammifications in many places through NASM.

    So, instead I ended up relying on existing NASM behavior
    as mentioned in my previous update to this bug report.

    On a side note...

    For now I've got to live with the existing preprocessor,
    not one that may one day supersede it... or not. To me a
    step by step improvement is way more valuable, than one
    big fat re-write, which I can't verify in any reasonable
    amount of time. Read: %DETOK, %STRTOK, or function-like
    syntax are -- as of writing this -- not an option to me.

    It's kinda like when someone suggests "use YASM". ;-)

     
  • Nickolay Yurchenko

    Logged In: YES
    user_id=806493

    I just ask you not to introduce any doubtful behaviour as
    usual for Nasm. This syntax is unsafe. How will you pass '}' to
    the macro?

    > For now I've got to live with the existing preprocessor,
    > not one that may one day supersede it... or not.

    No, not supersede - extend the right word. And fix a lot of
    bugs. I've sent a lot of comments with it in my last 'preproc.c'
    message (but I cannot see attaches in the mail list).
    Step-by-step improvement is slow. After a lot of patches
    preprocessor had to be refactored.

     
  • nasm64developer

    nasm64developer - 2003-09-12

    Logged In: YES
    user_id=804543

    > I just ask you not to introduce any doubtful
    > behaviour as usual for Nasm.

    I didn't introduce any new behavior.

    I just tried to fix the existing one that was broken.

    > This syntax is unsafe.

    Perhaps.

    I never claimed that the curly brace solution is ideal.

    > How will you pass '}' to the macro?

    Check out the testcases I posted earlier.

    In particular, read the comments they contain.

    As for the pros and cons of your massive preprocessor
    work -- that's a separate debate, which doesn't really
    belong into this particular bug report. I should not
    have brought it up here -- my apologies for doing so.

     
  • Nickolay Yurchenko

    Logged In: YES
    user_id=806493

    During single line macro function call '{' and '}' enclosure
    would be counted only if '{' is in the start of parameter:
    foo({a}) ; a
    foo(\{a}) ; \{a}
    So, escape syntax already exists. I think, the same must be
    done with multiline macro.

     
  • nasm64developer

    nasm64developer - 2004-02-15
    • status: open --> open-works-for-me
     
  • nasm64developer

    nasm64developer - 2004-02-15
    • priority: 5 --> 1
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.