Hi,
On Sun, 24 Apr 2016, Edmund Grimley Evans wrote:
The C standard has a somewhat unclear description of how the
preprocessor should work, but there is general agreement about what
was intended, and the general agreement leaves no real option for
alternative behaviour. Therefore, if two modern C compilers preprocess
differently, then one of them is buggy... I think it's TCC that is
buggy in this case. Has TCC always had this bug, or was it introduced
recently?
Actually, while the text of the standard is somewhat confusing, I think it
requires the behaviour of GCC. 6.10.3.6 (c99) Example 3, lists (somewhat
shortened) this example:
#define f(a) f(x * (a))
#define x 2
#define g f
#define t(a) a
t(t(g)(0) + t)(1)
which is required to expand to:
f(2 * (0)) + t(1)
from which we can infer that object-like macros _are_ considered for
expansion of function-like invocations ("g(0)" is replaced by "f(2 *
(0))", which can only happen if "g" is replaced by "f" first), while
function like macros are _not_ considered for non-function-like
invocations (that wouldn't make much sense anyway).
TCC get's this example correct as well, but problems appear when there are
nested invocations of this rule, as your next example shows:
Simplified test case:
#define Y(x) Z(x)
#define X Y
X(X(foo))
which tcc replaces by "Z(Y(1))" showing an inconsistency in TCC itself.
Both X should be replaced in the same way (ultimately to Z).
So, your bug entry seems quite appropriate.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
