g-rh@cca.CCA.COM (Richard Harter) (09/18/88)
In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >It is agreed that a Real ANSI-conforming C compiler might not supply a >separate preprocessor pass, but who cares? Such a C compiler would be >an instant commercial failure. I do not doubt your word, but... I currently work with Primos C and DEC's VAX C. I don't know how to make an in independent preprocessor run for these systems. If anyone can tell me how to do this, I would be enchanted to hear about it. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/19/88)
In article <33440@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes: >In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: [etc.] Not fair looking over my shoulder...I cancelled that article before anybody saw it (or so I thought). -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
seanf@sco.COM (Sean Fagan) (09/20/88)
In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >It is agreed that a Real ANSI-conforming C compiler might not supply a >separate preprocessor pass, but who cares? Such a C compiler would be >an instant commercial failure. I'm sure Microsoft will be sorry to hear that MSC 4.x and upwards (at least) and QuickC are doomed to be "an instant commercial failure." (True, they're not strictly conforming, yet, but they're trying to get there.) -- Sean Eric Fagan | "Never underestimate the bandwith of a pickup full of seanf@sco.UUCP | 9-track tapes!" - Eric Green (elg@killer) (408) 458-1422 | Any opinions expressed are my own, not my employers'.
smryan@garth.UUCP (Steven Ryan) (09/20/88)
>>It is agreed that a Real ANSI-conforming C compiler might not supply a >>separate preprocessor pass, but who cares? Such a C compiler would be >>an instant commercial failure. Intergraph markets the Greenhills compilers with its Clipper products. Greenhills does not use a separate preprocessor pass.
henry@utzoo.uucp (Henry Spencer) (09/20/88)
In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >It is agreed that a Real ANSI-conforming C compiler might not supply a >separate preprocessor pass, but who cares? Such a C compiler would be >an instant commercial failure. Not necessarily. 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. (I've written the code for this, so please don't try to tell me it can't be done.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/20/88)
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: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (09/20/88)
>In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >It is agreed that a Real ANSI-conforming C compiler might not supply a >separate preprocessor pass, but who cares? Such a C compiler would be >an instant commercial failure. As long as one can access "the proprocessor" via a command line option (or whatever) I don't think it matters much if it is a *separate program* or not. There are many many applications that use the C preprocessor that are not C programs. There is even a "calendar" program that uses the C preprocessor. If I couldn't access the preprocessor separately from the rest of the compilation then I'll just keep the preprocessor I already use. -- Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM
jim.nutt@p11.f15.n114.z1.fidonet.org (jim nutt) (09/21/88)
> From: seanf@sco.COM (Sean Fagan) > Organization: The Santa Cruz Operation, Inc. > Message-ID: <1292@scolex> > In article <3999@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >It is agreed that a Real ANSI-conforming C compiler might not supply a > >separate preprocessor pass, but who cares? Such a C compiler would be > >an instant commercial failure. > > I'm sure Microsoft will be sorry to hear that MSC 4.x and upwards (at > least) > and QuickC are doomed to be "an instant commercial failure." (True, > they're > not strictly conforming, yet, but they're trying to get there.) not to mention nearly every other ms-dos c compiler. a few have separate preprocessor passes (or supply a separate preprocessor [turbo c]), but most do not. jim nutt 'the computer handyman' -- St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!15.11!jim.nutt
warner@hydrovax.nmt.edu (M. Warner Losh) (09/26/88)
In article <4026@bsu-cs.UUCP>, dhesi@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@hydrovax.nmt.edu ...!unmvax!nmtsun!warner%hydrovax My spelling and views are my own. Only the letters have been changed...
leo@philmds.UUCP (Leo de Wit) (09/27/88)
In article <1205@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: [ ]... >The VAX-C compiler (the one from DEC) does not have a separate >preprocessor. You probably mean the VAX-VMS C compiler? This *HAS* a separate preprocessor, as far as I can see. Roaming about in SYS$SYSTEM revealed that there was a C.COM which does compilation, using a program named CPP.EXE (now doesn't that name sound familiar?). Because I sometimes needed to look at the output of the preprocessor (I think it's useful to be able to do this, but who am I?), I have a line in my LOGIN.COM: $ cpp :== $sys$system:cpp -isys$library: so I can say now cpp myfile.c which does the obvious thing. The only problem seems to be with the non-standard filenames in #include directives that are supported by VMS-C, e.g. in stdio.h: #include stddef but I think using the right logicals/symbols might solve even this (anybody any idea ?). Leo.