Try this:
%macro mmac 0
%endmacro
db mmac ; causes "expression syntax error"
; -- or --
$db mmac ; fails to trigger "orphan-labels"
The problem is that preproc.c's expand_mmacro()
function inserts a ":" token after the "db". As
a result we get:
db: ; ":" is not a valid argument to "db"
; -- or --
$db: ; with the trailing ":", it's no orphan
The fix is to only insert the ":" token, if the
type of the "label" token is not TOK_WHITESPACE.
diff -u preproc.c.0.98.38 preproc.c.new
--- preproc.c.0.98.38
+++ preproc.c.new
@@ -4040,7 +4040,8 @@
{
while (label->next)
label = label->next;
- label->next = tt = new_Token(NULL,
TOK_OTHER, ":", 0);
+ if ( label->type != TOK_WHITESPACE )
+ label->next = tt = new_Token(NULL,
TOK_OTHER, ":", 0);
}
}
}
With that we get:
db ; no operand for data declaration -- good!
; -- or --
$db ; orphan label -- good!
The other "testcases" seem to remain unaffected,
just as desired:
;db
;db:
;db mmac ; differs as mentioned
;db:mmac
;db :mmac
;db : mmac
;db 1,mmac
;db:1,mmac
;db :1,mmac
;db : 1,mmac
;$db
;$db:
;$db mmac ; differs as mentioned
;$db:mmac
;$db :mmac
;$db : mmac
;$db 1,mmac
;$db:1,mmac
;$db :1,mmac
;$db : 1,mmac
Logged In: YES
user_id=806493
As I understand, you ask not to add missing colon to a label
(or something looking like a label) standing before macro in
macro call?
Logged In: YES
user_id=804543
Only in the case where it would be wrong to do so.
Try the examples I gave.
Also, try them with "db" replaced by e.g. "label".
Logged In: YES
user_id=806493
I think, 'db mmac' is wrong itself.
It may be useful only if you use %00 (or %:)
%macro mmac 0
%: 10
%endm
db mmac ; db 10
Or if you use my feature:
%macro mmac 0
%return 10
%endm
db %invoke(mmac) ; db 10
Anyway, I think, preprocessor should not know internal
assembler logic (of course, base syntax should be compatible)
. In this case it should not bother about db, resb and so on.
That's enough if user know about it. There only should be
possibility to overload assembler syntax.
Logged In: YES
user_id=804543
The change mentioned in this SF report fixes two cases.
First, in case of "db mmac" the preprocessor inserted a
colon after the db. As a result the evaluator produced
an "invalid expression syntax" error if the conditional
operator wasn't supported, or a "missing '?'" error if
the conditional operator was supported.
The expected behavior in the "db mmac" case would be to
not insert the colon. That way db would complain about
a missing operand, since mmac expands to nothing.
Second, in case of "$db mmac" the preprocessor inserted
a colon after $db. As a result, the parser failed to ge-
nerate an "orphan label" warning.
The expected behavior in the "$db mmac" case would be to
not insert a colon. That way $db would emit its "orphan
label" warning, since mmac expands to nothing.
All other scenarios (see my testcases) remain unchanged.
Whether "db mmac" or "$db mmac" makes sense or not, is a
different matter. The important thing is that NASM pro-
duces the proper error message. Which it didn't.
Btw, without the change mentioned in the SF report, the
preprocessor sufferes from a memory leak, because of the
wrongly inserted colon.
(I only found this problem after wondering about those
odd error messages from the evaluator, and tracing some
memory leaks in the preprocessor. ;-)