Xref: utzoo gnu.gcc:275 comp.lang.c:16994
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bionet!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: gnu.gcc,comp.lang.c
Subject: Re: Problems with GCC and/or VAX LINK
Message-ID: <9861@smoke.BRL.MIL>
Date: 16 Mar 89 23:25:08 GMT
References: <18426@iuvax.cs.indiana.edu> <1732@levels.sait.edu.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <1732@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
>Mind you, this is still a problem.  A program section which is
>conditionally  _not_ compiled should be treated like a comment -- it
>shouldn't matter what's inside the #ifdef/#endif.

More precisely, it should be scanned for preprocessor # directives
so it can properly tell where the matching #else or #endif is.
The only other form of syntax checking performed on a skipped group
is the parsing into "preprocessing tokens".  The pANS explicitly
states that an unmatched ' or " produces "undefined behavior", so
GCC is allowed to complain about it (or accept it as just a character).

This tokenizing behavior is considerably more structured than many
existing C preprocessors support (notably the Reiser cpp).  One is
not allowed to have arbitrary garbage #if 0'ed out; it must consist
of a sequence of valid preprocessing tokens.