Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.lang.c Subject: Re: C compilers with integrated preprocessors Message-ID: <4026@bsu-cs.UUCP> Date: 20 Sep 88 16:05:35 GMT References: <5438@techunix.BITNET> <13544@mimsy.UUCP> <779@proxftl.UUCP> <13604@mimsy.UUCP> <3999@bsu-cs.UUCP> <33440@cca.CCA.COM> <1988Sep19.213313.13262@utzoo.uucp> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 27 In article <1988Sep19.213313.13262@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >For one thing, most people buy C compilers to compile C, >not to serve as general-purpose macro processors. For another, it's quite >possible to have an integrated preprocessor and still support the -P and >-E options to get preprocessed output. Henry Spencer was following up to an article that I cancelled a few hours after I wrote it (because my comment syntax was wrong, not because of the statement about preprocessors), but so long as everybody is following up to my supposedly nonexistent article, I'll defend myself. When I say "separate preprocessor pass" that should be meant to include "the ability to do preprocessing and nothing else". The preprocessor could be integrated, but so long as you can do "cc -E" etc. and make the whole compiler just act like a preprocessor, that's fine. The reason this is important is because without this it can be very difficult to track down the reason for a compiler diagnostic that is caused by a badly-formed #define. Also, if there is a conflict between a variable in a system-provided #include file and one that you declare, the error message from the compiler may not refer to your own source at all, so it helps greatly to be able to see the expanded input to the C parses. -- Rahul Dhesi UUCP:!{iuvax,pur-ee,uunet}!bsu-cs!dhesi