C preprocessor question
guy at gorodish.UUCP
guy at gorodish.UUCP
Thu Jan 29 17:58:26 AEST 1987
>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.
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list