Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#519 Trailing comma in multi-line macro loses last argument

open
nobody
5
2014-08-23
2010-11-17
Michael Rolle
No

If the final argument in a multiline macro is blank (that is, there is a trailing comma), this argument is lost and the macro receives only the arguments up to the last comma.

This bug was also filed in 2004, and is still Open, and include a change to the source which would fix the problem.
That bug was disposed as Works For Me.
Obviously this has never been fixed, and I cannot find anything in the documentation that shows this as a feature.

I have 2.09.03, which I built myself from source code, on Windows XP 64-bit.
Here is an example:

%macro MAC 1-*
%0 args
<%1> <%2> <%3> <%4>
%rotate 1
<%1> <%2> <%3> <%4>
%endmacro
MAC A,B,
MAC A,B,,
MAC A,B,{} ; 3 arguments

The output from "nasm -E ..." is:

%line 7+1 ...
2 args
%line 7+0 ...
<A> <B> <> <>
<B> <A> <> <>
%line 8+1 ...
3 args
%line 8+0 ...
<A> <B> <> <>
<B> <> <A> <>
%line 9+1 ...
3 args
%line 9+0 ...
<A> <B> <> <>
<B> <> <A> <>

I worked around this problem as shown in the example, with a {} value, which is equivalent to an empty argument, but the preprocessor correctly records its presence.
Another workaround is your macro can accept and ignore one additional optional argument, is to follow the call with an extra comma. The macro will see the empty last "real" argument, and may or may not see the one after the trailing comma, depending on whether this bug is fixed or not.

If this is a feature, then please amend the documentation. Or perhaps it should be considered a feature, now that it has been in place for several years. I think that the documentation should include the use of {} to force recognition of the last argument.

Discussion