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