🚀 go-pugleaf

>	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.