C compilers with integrated preprocessors
M. Warner Losh
warner at hydrovax.nmt.edu
Mon Sep 26 07:40:17 AEST 1988
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...
More information about the Comp.lang.c
mailing list