tanner@cdis-1.uucp (Dr. T. Andrews) (10/05/89)
I should be interested to know the latest ANSI wisdom on a construct
requesting that token BLUNGE be replaced by itself:
#define BLUNGE BLUNGE
Intended use is to "remember" that we have done a "typedef" by
defining a preprocessor symbol which has the same name as the type.
--
He cuts half of passenger service | {bpa,uunet}!cdin-1!cdis-1!tanner
Mulroney: "cold froze our brains" | {attctc gatech!uflorida}!ki4pv!cdis-1!tannerhenry@utzoo.uucp (Henry Spencer) (10/12/89)
In article <7657@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >I should be interested to know the latest ANSI wisdom on a construct >requesting that token BLUNGE be replaced by itself: > #define BLUNGE BLUNGE ANSI C (draft of last Oct) specifically says that the macro name is not expanded if encountered within the body of the macro. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dfp@cbnewsl.ATT.COM (david.f.prosser) (10/13/89)
In article <7657@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >I should be interested to know the latest ANSI wisdom on a construct >requesting that token BLUNGE be replaced by itself: > #define BLUNGE BLUNGE When BLUNGE is replaced, the attempted recursion is detected and the macro is left unchanged. A more complicated example would be #define A B #define B A A in which A is replaced by B and during the rescan B is replaced by A. The next rescan detects the recursion, and this A is unreplaced and is the result. Yes, this implies that the macro replacement algorithm must keep track of potentially lots of information. Dave Prosser ...not an official X3J11 answer...
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/13/89)
tanner@cdis-1.uucp (Dr. T. Andrews) writes: > #define BLUNGE BLUNGE >Intended use is to "remember" that we have done a "typedef" by >defining a preprocessor symbol which has the same name as the type. Why not use a different symbol? Seems like an unnecessary complication.
diamond@csl.sony.co.jp (Norman Diamond) (10/13/89)
In article <7657@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >I should be interested to know the latest ANSI wisdom on a construct >requesting that token BLUNGE be replaced by itself: > #define BLUNGE BLUNGE This works. ANSI says that nested replacements do not recognize a macro name which has already been replaced. It's not so clear with more complicated examples though. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
dhesi@sunscreen.UUCP (Rahul Dhesi) (10/13/89)
In article <1989Oct12.161500.23828@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> #define BLUNGE BLUNGE > >ANSI C (draft of last Oct) specifically says that the macro name is not >expanded if encountered within the body of the macro. But is BLUNGE within BLUNGE? The wine may be within the glass, but is the glass within the glass? Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/14/89)
In article <7657@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >I should be interested to know the latest ANSI wisdom on a construct >requesting that token BLUNGE be replaced by itself: > #define BLUNGE BLUNGE That's allowed, and the replacement string's BLUNGE will not be expanded. However, note that some pre-ANSI C preprocessors may do this differently.