Preprocessor strings

[cottrell at NBS-VMS]

/*
> I'll try to be brief, I'm really sick of this issue...

I think Henry is finding out (like I did) that strong opinions are expensive

> This is net.lang.c, not net.unix or att.lang.c...

A little ethnocentrism wouldn't hurt. TPC begat UNIX begat C.

> The C preprocessor extensions strike me as being just as ugly and bogus
> as the Reiser extensions, with the quibble that the Reiser extensions
> at least appear in a set of widely used C implementations.

Yeah, they're BOTH wrong. What we really need is some way to delimit
tokens for substitution ON BOTH SIDES, possibly with backquotes:

	#define	CTL(x)		('`x`' & 31)
	#define	LAB(pfx,num)	`pfx``num`:
	CTL(z)		=>	('z' & 31)
	LAB(x,1)	=>	x1:

This would have to be in addition to garden variety substitution for
compatibility. Of course, then we have the problem of quoting "`"!
Maybe someone should hack up DEC's macro assembler to just do macros :-)

I also seem to recall reading (in "The C Puzzle Book") that "the pre-
processor doesn't know C." Have we abandoned this? If so, I find that
regretable. 

As a final note, how about a ruling on this technique? We used to have
one project-wide include file for all global definitions. It was heavily
commented, with lines of stars /******...*******/ separating sections.
We ran it thru cpp to remove the comments which reduced it from 6k to 4k 
chars. We then included the ".i" file. However, all the defines were
expanded, so we used the trick of:

/**/#define	WIDGET	BLIVET

Cpp stripped off the comments, but didn't expand defines because the
sharp was not the first char, leaving it to be expanded when finally 
included! Will this be legal, or will I have to find another kluge?

	jim		cottrell at nbs
*/