Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!decwrl!hplabs!hp-ses!hpcuhb!hpesoc1!hpda!motcsd!apple!gem.mps.ohio-state.edu!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.std.c
Subject: Re: BUG in free() on sunOS 4.0.x
Message-ID: <2483@auspex>
Date: 23 Sep 89 19:55:00 GMT
References: <3346@solo12>
Lines: 53

>ok@cs.mu.oz.au (Richard O'Keefe) writes:
>\...     #if 0
>\...     ...
>\        #endif 0
>\(a)            ^ this token is not legal in dpANS C; V.3 tends not to like it
>
>What!?  The rest of the line isn't ignored?  And what was the very good reason
>the ANSI committee decided so?

From the Rationale (presented without comment - I neither endorse nor
reject their rationale, I merely present it):

	   Various proposals were considered for permitting text other
	than comments at the end of directives, particularly "#endif"
	and "#else", presumably to label them for easier matchup with
	their corresponding "#if" directives.  The Committee rejected
	all such proposals because of the difficulty of specifying
	exactly what would be permitted, and how the translator would
	have to process it.

Three notes:

	1) V.3 "tends not to like it", but merely spits out a warning -
	   the code will still compile.

	2) If you put "/*" and "*/" around the token, the resulting text
	   is legal (assuming, of course, that there's no "*/" in the
	   token, etc.).

	3) If there already exist compilers that disallow extra tokens
	   like that, one should consider replacing them with comments
	   *anyway*.

>\(b) You should not use this technique to comment out text in a C program; new
>\C compilers are allowed to complain about mismatched quotes when they see
>\"don't" and other such text, and some _do_.
>
>I remember the discussion, but I don't recall the very good reason (here we
>go again) why those compilers could complain.  Quality of implementation?
>That's another point for Sun, 'cause their cpp works. :-)

Sun's "cpp" is derived from various versions of the AT&T preprocessor
(the precise version depends on the SunOS release); the credit doesn't
go to Sun, by and large, for it working in that particular case - you'll
probably find most, if not all, other Reiser-based "cpp"s (well, "cpp"s
based on Reiser's "cpp", not based on Reiser himself, but you knew what
I meant :-)), handle that particular case in the fashion you desire. 

The SunOS 4.x "cpp" is, BTW, based on the S5R3 "cpp", but the warning for
extra tokens at the end of "#else"/"#endif" was put under the control of
a "-p" (for "portability") flag to "cpp" (used, as I remember, only by
the S5-environment "lint" when it is given the "-p" flag) because the
practice was so widespread.