From a545685ab48782dc7b12f47a931320e071a2699f Mon Sep 17 00:00:00 2001 From: Stephen Heumann Date: Mon, 26 Feb 2024 22:30:48 -0600 Subject: [PATCH] Use more correct logic for expanding macros in macro parameters. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Specifically, this affects the case where a macro argument ends with the name of a function-like macro that takes 0 parameters. When that argument is initially expanded, the macro should not be expanded, even if there are parentheses within the macro that it is being passed to or the subsequent program code. This is the case because the C standards specify that "The argument’s preprocessing tokens are completely macro replaced before being substituted as if they formed the rest of the preprocessing file with no other preprocessing tokens being available." (The macro may still be expanded at a later stage, but that depends on other rules that determine whether the expansion is suppressed.) The logic for this was already present for the case of macros taking one or more argument; this extends it to apply to function-like macros taking zero arguments as well. I'm not sure that this makes any practical difference while cycles of mutually-referential macros still aren't handled correctly (issue #48), but if that were fixed then there would be some cases that depend on this behavior. --- Scanner.pas | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Scanner.pas b/Scanner.pas index ccb767a..d445449 100644 --- a/Scanner.pas +++ b/Scanner.pas @@ -2187,7 +2187,7 @@ else begin if not tcPtr^.expandEnabled then inhibit := true; if tcPtr = pptr^.tokens then - if (mPtr <> nil) and (mPtr^.parameters > 0) then + if (mPtr <> nil) and (mPtr^.parameters >= 0) then inhibit := true; if (mPtr <> nil) and (not inhibit) then Expand(mPtr)