C compilers with integrated preprocessors

[M. Warner Losh]

In article <4026 at bsu-cs.UUCP>, dhesi at bsu-cs.UUCP (Rahul Dhesi) writes...
> 
>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 VAX-C compiler (the one from DEC) does not have a separate 
preprocessor.  I've never needed it.  What I have had to do was have the
compiler generate a listing with the macros expanded.  The one thing this
compiler can do that all cpp's that I've seen is produce a blow-by-blow of
the macro expantion, so you know *EXACTLY* what went wrong w/o having to
dink with the output of cpp on a hacked up version of your code.  This is
all that needed in most cases.  If you want a cpp, then use the one that
the Free Software Foundation wrote.

>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.

I agree with this.  One must see what was produced, however, it needn't be 
exactly the same thing that compiler uses for the rest of it's job.  I find 
the compiler listings from the VAX-C compiler easier to work with than the 
RAW output of CPP.

>Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
--
Warner Losh
warner at hydrovax.nmt.edu		...!unmvax!nmtsun!warner%hydrovax
My spelling and views are my own.  Only the letters have been changed...