Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-unix!sri-spam!ames!oliveb!sun!gorodish!guy From: guy@gorodish.UUCP Newsgroups: comp.bugs.4bsd,comp.lang.c Subject: Re: C preprocessor question Message-ID: <12300@sun.uucp> Date: Thu, 29-Jan-87 02:58:26 EST Article-I.D.: sun.12300 Posted: Thu Jan 29 02:58:26 1987 Date-Received: Sat, 31-Jan-87 02:28:51 EST References: <818@wjvax.wjvax.UUCP> Sender: news@sun.uucp Reply-To: guy@sun.UUCP (Guy Harris) Followup-To: comp.lang.c Organization: Sun Microsystems, Mountain View Lines: 37 Keywords: preprocessor, UNIX, BSD Xref: watmath comp.bugs.4bsd:156 comp.lang.c:883 >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.