devine@shodha.dec.com (Bob Devine) (10/04/89)
In article <JFR.89Oct4133101@tel3.tel3.tel.vtt.fi>, jfr@tel3.tel3.tel.vtt.fi (Jim Reilly) writes: > The `#endif sparc` > never caused any complaints on the sun's normal C compiler, but our > 'Designer C++' compiler doesn't like it. Is this just something > funny with the c compilers on the SUN ? At least I didn't find > it in any C or ANSI C manuals around here. > > #ifdef sparc > .... other stuff deleted .... > #endif sparc The ANSI C spec forbids the placing of anything except a comment after the `#endif' (section 3.8.1). Ditto for `#else'. The acceptance of a token after the cpp directives was never consistently followed. Some compilers took them, others didn't. I've seen programs that had it both ways. Bob Devine
jfr@tel3.tel3.tel.vtt.fi (Jim Reilly) (10/05/89)
I have a question on types.h for our Sun 386i, it has the following definition for sparc. The `#endif sparc` never caused any complaints on the sun's normal C compiler, but our 'Designer C++' compiler doesn't like it. Is this just something funny with the c compilers on the SUN ? At least I didn't find it in any C or ANSI C manuals around here. /* @(#)types.h 2.22 88/01/13 SMI; from UCB 7.1 6/4/86 */ .... other stuff deleted .... #ifdef sparc .... other stuff deleted .... #endif sparc I just use a local types.h with the superfluous sparc commented out, but enquiring minds want to know... -- Internet Mailbox: reilly@tel.vtt.fi UUCP Mailbox: ...!arpa!router.funet.fi!vtttel!reilly ...!mcvax!kth!draken!tut!router!vtttel!reilly
henry@utzoo.uucp (Henry Spencer) (10/05/89)
In article <JFR.89Oct4133101@tel3.tel3.tel.vtt.fi> jfr@tel3.tel3.tel.vtt.fi (Jim Reilly) writes: >... The `#endif sparc` >never caused any complaints on the sun's normal C compiler, but our >'Designer C++' compiler doesn't like it. Is this just something >funny with the c compilers on the SUN ? At least I didn't find >it in any C or ANSI C manuals around here. Many Unix implementations have historically permitted putting any sort of garbage after `endif', but neither K&R nor ANSI C has ever endorsed putting anything but a comment there, and many compilers not derived from the original Unix ones are fussier about this. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cpcahil@virtech.UUCP (Conor P. Cahill) (10/05/89)
In article <JFR.89Oct4133101@tel3.tel3.tel.vtt.fi>, jfr@tel3.tel3.tel.vtt.fi (Jim Reilly) writes: > it has the following definition for sparc. The `#endif sparc` > never caused any complaints on the sun's normal C compiler, but our > 'Designer C++' compiler doesn't like it. Is this just something > funny with the c compilers on the SUN ? At least I didn't find > it in any C or ANSI C manuals around here. The data to the right of the #else, #endif, etc used to be ignored, but this was deemed to be unacceptable for certain compiler environments. It is a no no, but most compilers just compain about it with a warning, but compile anyway. There was never any real use of this data, it was just a comment that was allowed to exist without the /* */. The safe way to do this is to always use the /* label */ which will work in either of the environments. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
diamond@csl.sony.co.jp (Norman Diamond) (10/05/89)
In article <JFR.89Oct4133101@tel3.tel3.tel.vtt.fi> jfr@tel3.tel3.tel.vtt.fi (Jim Reilly) writes: >`#endif sparc` >never caused any complaints on the sun's normal C compiler, but our >'Designer C++' compiler doesn't like it. Is this just something >funny with the c compilers on the SUN ? It's something funny with pcc-based compilers. It's something funnier with SUN to depend on this particular undefined behavior. Extra tokens after #endif (or #else) are not permitted by ANSI or K&R-1, though the processor (e.g. pcc) is not required to notice them. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.