Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Incrementing of preprocessor symbols
Message-ID: <5766@brl-smoke.ARPA>
Date: Thu, 16-Apr-87 09:36:09 EST
Article-I.D.: brl-smok.5766
Posted: Thu Apr 16 09:36:09 1987
Date-Received: Sun, 19-Apr-87 05:47:33 EST
References: <3424@vrdxhq.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20
Keywords: C #define

In article <3424@vrdxhq.UUCP> deller@vrdxhq.UUCP (Steven Deller) writes:
>I would note that any self-respecting macro facility for any assembler can do 
>this sort of thing with its eyes closed and one macro expansion behind its 
>back.  If as I am beginning to suspect, this is not possible with C, then 
>perhaps the C standards committee might take note.

As you surmised, it is not possible to generate unique labels like
this in the course of C preprocessor macro expansion.  The X3J11
committee is aware of it, but haven't been persuaded that increasing
the power of C's macro processing is sufficiently worthwhile to
counter the fact that some code would break due to the change.

Dave Prosser among others has come up with some very nice proposals
for more powerful and/or flexible C preprocessing, and a number of
X3J11 committee members favor the idea, but not enough to get it
into the standard.

Most people who really need this facility use a separate processor,
such as UNIX's "m4", before compilation.  It's pretty easy to have
"make" add processing like this to the compilation phase.