Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!taumet!steve From: steve@taumet.com (Stephen Clamage) Newsgroups: comp.lang.c Subject: Re: preprocessor bug Message-ID: <452@taumet.com> Date: 13 Sep 90 15:20:00 GMT References: <31530015@hpcvia.CV.HP.COM> <141513@sun.Eng.Sun.COM> <1982@jura.tcom.stc.co.uk> Organization: Taumetric Corporation, San Diego Lines: 59 erik@tcom.stc.co.uk (Erik Corry) writes: >In article <141513@sun.Eng.Sun.COM> eager@ringworld.Eng.Sun.COM (Michael J. Eager) writes: >> >>The preprocessor is supposed to insert whitespace after the expansion >>of a macro. If it doesn't and the define is as described, there seems >>to be a preprocessor bug. >> >Are you sure? The ULTRIX VAX I am using will preprocess: > #define TRUE -1 > int c; > c=TRUE; >into > int c; > c=-1; >Which gives a compiler warning because it is interpreted as an >old-fashioned version of c-=1. Does this mean the compiler here >is not pcc compliant? Not ANSI compliant? (no surprises there). >Which standard defines the behaviour you describe? One reason the ANSI committee spent so much time on defining preprocessor behavior was that, so far as I know, there was no complete published specification of what the preprocessor was supposed to do. When a programmer wondered what the effect of a construct was, the solution was to try it and see; in the programmer's mind, that became the definition. As long as no other preprocessor was ever used on that code, the code was ok. The next preprocessor took a different approach, and the code failed. There was no specification at which to point and say "this proves the preprocessor is wrong." It is not exactly true that ANSI requires the preprocessor "to insert whitespace after the expansion of a macro." The result of macro expansion cannot result in combining two tokens into one, as in c=TRUE; becoming equivalent to c =- 1; In that sense, a preprocessor which tranlates text into text (as opposed to one which converts into internal tokens or other data structures) must insert white space in some cases. If the compiler is going to warn about =-, then this is such a case. >(I am not interested in hearing comments on #define TRUE -1. It >is irrelevant.) Sorry, I'm going to comment anyway. Because not all compilers are ANSI- conforming, and because among buggy ANSI compilers and non-ANSI compilers there are differences in preprocessor behavior, it is safer to use #define TRUE (-1) This will prevent the above class of problem from occurring with any kind of preprocessor. Because -1 is an expression (negation of constant 1), it should for safety be enclosed in parentheses, just as you would with #define SUM (b + c) -- Steve Clamage, TauMetric Corp, steve@taumet.com