Al,
It doesn't. 6.10.3p11: "If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined." You are asking for identical nasal demons from two implementations, when it's not even promised that the same kind will fly on two invocations of the same implementation...
So what you are saying is that this is a bug in the header. This is the approach I would favor.
Seriously, this is undefined behaviour *and* it's extermely hard to come up with self-consistent semantics for it. Standard doesn't even try and implementations are doing whatever's more convenient at the moment. Try to think of it and you'll come up with really ugly corner cases very fast.
Unless gcc comes up with consistent behavior every time I would not expect this usage to hang around very long in the header.
What we probably ought to do is a warning when such stuff happens.
You mean a more easy to understand message. -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek@xxxxxxxxxxxx Source code analysis http://www.knosof.co.uk -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html