#46 abandon %00 in favor of %:

[nasm64developer]

See subject. (This is what I have done to
my local forked version.)

Since %0 expands to the parameter count of
a multi-line macro, I find %00 confusing.

Since %00 expands into a label name, I do
suggest that we abandon it in favor of %:.

The leading % would remind you of the pre-
processor, while the trailing : would re-
mind you of labels. Easy to remember, IMO.

To achieve this, the following preproc.c
changes will be required:

in tokenise(), before '%' results in TOK_OTHER
} else if ( *p == ':' ) {
p++;
type = TOK_PREPROC_ID;
}

in expand_mmac_params(), add this condition
tline->text[1] == ':'

in expand_mmacro(), replace %00 with %: and %00
if ( t->type == TOK_PREPROC_ID &&
t->text[1] == ':' ) {
dont_prepend = -1;
x = label;
if ( !x ) {
continue;
}
} else if ( t->type == TOK_PREPROC_ID &&
t->text[1] == '0' &&
t->text[2] == '0' ) {
// warn: "should use '%:' instead of '%00'"
dont_prepend = -1;
x = label;
if ( !x ) {
continue;
}
}

I'll post a documentation snippet for the
manual on the mailing list (since it would
get mangled by the SF web interface).

[nasm64developer]

documentation snipped for %:

[Nickolay Yurchenko]

Logged In: YES
user_id=806493

%: looks reasonable, but it returns only a symbolic name of
label. If you want to use it as not-orhpan label you should add
a colon to it:
%::
I mean, using %: may mislead somebody. But, of course, %
00 is more mistaken.

[nasm64developer]

Logged In: YES
user_id=804543

As stated in my documentation snippet, attached
to this SF request. :)

[p1ranha-rob]

Another use of this syntax also applies to the following
judiciously modified/simplified snippet:

%push

%assign %$arg 8

%macro local 0
%xdefine %[%:] ebp-%[%$arg]
%assign %$arg %$arg+8
%endmacro

_main:

.myvar local ; results in _main.myvar defined as ebp-8
mov rax, [.myvar]

%pop

I personally prefer the %: syntax as it is slightly less confusing than %00.
However, bear in mind that the previous snippet is modifying the local label
for it's own use and that this behavior should continue being supported
following any syntax change.