🚀 go-pugleaf

>I have a question about the C preprocessor.  I have the following code
>fragment, which fails to compile on my system (4.2BSD):

It ain't gonna work on S5, either.

>The #if chokes for some reason.  Can anyone in comp.lang.c see my error?
>If there is no error, is this a known bug of the 4.2BSD cpp?

Well, it's certainly "known" in some sense now, but I never knew
about it until now.  I don't know if the fact that it has persisted
in the Reiser preprocessor (as used in most UNIX C compilers) to this
day indicates that it wasn't known or that it was known but nobody
wanted to fix it.

K&R isn't very clear on what happens to macros inside the
"conditional-expression" in an "#if".  The Reiser preprocessor will
expand macros that have no formal arguments, but doesn't seem to
bother with macros that have formals.  The ANSI C draft of October 1,
1986 says that

	In a controlling constant expression, each identifier
	currently defined as a macro name is replaced by its token
	sequence (except for those identifiers modified by "defined",
	just as in normal text.

This doesn't distinguish between "object-like" and "function-like"
macros, although the language seems to be written specifically around
object-like macros (since when a "function-like" macro call is
expanded, the identifier and the actual argument list, not just the
identifier, is replaced).  This requires some clarification.

Unless there's some compelling reason not to do so, I think that both
kinds of macros should be expanded (the Principle of Least Surprise
rules here, and you certainly were surprised by the behavior of the
Reiser preprocessor).  I don't know whether the Reiser preprocessor's
reluctance to expand "function-like" macro calls here is caused by
conceptual problems with doing that or implementation problems.