matt@iquery.UUCP (Matt Reedy) (03/22/88)
Has anyone else noticed this on the 3B2 (using C Programming Languages
Issue 4 Version 0)?
Code fragment:
#ifdef XXXXX
junk junk
#include junk
#endif
main ()
{
return 0;
}
If it is compiled using 'cc -c -O junk.c', cpp says:
junk.c: 3: bad include syntax
Why is cpp trying to interpret the #include when the #ifdef is NOT true?
It doesn't complain about the 'junk junk' line, only the #include line!
--
Matthew Reedy harvard!adelie!iquery!matt
Programmed Intelligence Corp. (512) 822 8703
830 NE Loop 410, Suite 412 "just ONE MORE compile...."
San Antonio, TX 78209-1209gandalf@csli.STANFORD.EDU (Juergen Wagner) (03/27/88)
The problem with your cpp is that all the lines starting with # have to be valid syntax, i.e. "junk junk" is not relevant because it is just text and cpp doesn't know if this is correct or not, but "# include junk" is invalid because is violates cpp syntax. BTW, I tried it on Suns, and there are no error messages. -- Juergen Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA
karl@haddock.ISC.COM (Karl Heuer) (03/30/88)
In article <3127@csli.STANFORD.EDU> gandalf@csli.stanford.edu (Juergen Wagner) writes: >The problem with your cpp is that all the lines starting with # have to >be valid syntax, i.e. "junk junk" is not relevant because it is just text >and cpp doesn't know if this is correct or not, but "# include junk" is >invalid because is violates cpp syntax. "#include junk" is legal (in ANSI C, anyway) if "junk" is a macro that expands into a quoted or embroketed header name. Thus, #ifdef junk #include junk #endif should be legal. This is indeed a bug in certain preprocessors. Similarly, I believe that the warning produced by #ifdef vms #ifdef foo$bar /* a valid name, in VMS */ #endif #endif on non-VMS systems is inappropriate, though I haven't yet determined what the latest dpANS says about this. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint Followups to comp.lang.c only.
sarge@sham.Berkeley.EDU (Steven Sargent) (04/02/88)
In article <109@iquery.UUCP>, matt@iquery.UUCP (Matt Reedy) writes: > Has anyone else noticed this on the 3B2 (using C Programming Languages > Issue 4 Version 0)? > > Code fragment: > > #ifdef XXXXX > junk junk > #include junk > #endif > > main () > { > return 0; > } > > If it is compiled using 'cc -c -O junk.c', cpp says: > > junk.c: 3: bad include syntax > > Why is cpp trying to interpret the #include when the #ifdef is NOT true? > It doesn't complain about the 'junk junk' line, only the #include line! > > -- > Matthew Reedy harvard!adelie!iquery!matt > Programmed Intelligence Corp. (512) 822 8703 > 830 NE Loop 410, Suite 412 "just ONE MORE compile...." > San Antonio, TX 78209-1209 Ain't just 3b2, y'know: anybody using C 4.0 gets the same "benefit." I have to compile on UNIX and VMS, and so ran into this myself. Apparently TPC is running a full-employment program, and rather than building roads and dams, they keep busy by making annoying changes to cpp... here's another one: #ifdef vms do$vms$stuff$with$lots$of$signs #else vms do something else #endif vms The new improved cpp prints warnings about "tokens after directive (ignored)" after the #else and #endif lines. Not fatal to the compilation, but distracting to look at, and no help. (Yes, I can sed my source and fix the damn things -- certainly #endif /* vms */ is an acceptable solution. But why do they bother?) S. --- "I'm sorry... you must have me confused with some other plate-lipped white girl named Irene." -- Good Girls #2 Steven Sargent ARPA Internet: sarge@scam.berkeley.edu MILnet: sarge%scam.berkeley.edu@ucbvax.berkeley.edu TPCnet: {anywhere at all, really}!ucbvax!scam!sarge
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (04/03/88)
In article <2023@pasteur.Berkeley.Edu>, sarge@sham.Berkeley.EDU (Steven Sargent) writes: > #else vms > do something else > #endif vms > > The new improved cpp prints warnings about "tokens after directive > (ignored)" after the #else and #endif lines. Not fatal to the > compilation, but distracting to look at, and no help. (Yes, I can > sed my source and fix the damn things -- certainly > #endif /* vms */ > is an acceptable solution. But why do they bother?) They bother because it is nice to be warned if you entered something that looks like it means something but doesn't. There is nothing worse (well not really) than software that silently ignores input that it doesn't understand. A better example would be: #ifdef vms vax Did you really mean: #if defined(vms) && defined(vax) or perhaps: #if defined(vms) || defined(vax) In fact, most CPPs take it to mean: #ifdef vms /*vax*/ I for one certainly appreciate it when CPP warns me that it has ignored something that I didn't explictly mark as a comment. Similarly, how would you like it if on some system prompt-> mail jerome laurence maurice only sent mail to the first name on the list and silently ignored Larry and Moe? Designing a program that only looks at the first argument and silently ignores the rest would be really silly right? Also, as a matter of style, #ifdef vax or #if defined(vax) #else /*vax*/ #endif /*vax*/ isn't nearly as good as #ifndef vax or #if !defined(vax) #else /*vax*/ #endif /*vax*/ If the "if" and the "end" are far apart, the comments around the #else /*vax*/ ... machine specific code ... #endif /*vax*/ certainly make it look to someone that has to maintain your code that the enclosed section is the code intended for use when "vax" IS defined, not when it ISN'T defined.
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/03/88)
In article <17983@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >> >They bother because it is nice to be warned if you entered something >that looks like it means something but doesn't. There is nothing >worse (well not really) than software that silently ignores input that >it doesn't understand. You are right of course. This is such a widely used idiom though that cpp should be changed to allow it. I heard ATT-IS (or whatever its called these days) changed cpp to allow tokens after the closing # directives as long as it (they?) was an exact match with the corresponding opening # directive. But, incredibly it would complain about comments after the # directives! This is so stupid! Maybe I should sell my AT&T stock. Sigh. Is anyone at ATT-IS listening that would care to admit to this botch if it is true? -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)