Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Re: C preprocessor question
Message-ID: <12351@sun.uucp>
Date: Thu, 29-Jan-87 16:42:22 EST
Article-I.D.: sun.12351
Posted: Thu Jan 29 16:42:22 1987
Date-Received: Sat, 31-Jan-87 04:24:36 EST
References: <818@wjvax.wjvax.UUCP> <1493@nonvon.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 33

>	try running 'cc -E file.c' for some clues.
>	this will give you a output essentially a file
>	which is what your program looks like to the actual
>	c compiler after macros are expanded.

The problem is not that "ccom" is choking, it's that "cpp" is
choking.  Running "cc -E file.c" in this case will give the exact
same diagnostic as the regular "cc" did, so it won't help a bit.

>CPP evaluates the macro 'GROUP' with arguments 0,0
>to be:
>
>(((0) << 8) | ( 0 ))
>
>which is not a valid c line if it is stand alone.

The problem is that "cpp" *isn't* evaluating the macro "GROUP" - it's
getting a syntax error.  The "cpp" grammar doesn't include anything
with a macro-call-with-arguments syntax, so the parser gives up in
disgust.  The fact that it's not valid if it stands alone is
irrelevant; it *doesn't* stand alone, because it has a "#if" in front
of it.

What it arguably *should* have done is expand the macro, giving

	#if (((0) << 8) | ( 0 ))

which *is* a valid C line (given that "C" includes preprocessor
commands), and is equivalent to

	#if 0

which tells it not to include the text surrounded by #if/#endif.