Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!dkuug!diku!rimfaxe.diku.dk!thorinn
From: thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.std.c
Subject: Re: Macro substitution in character literals
Keywords: Macro substitution, C preprocessor
Message-ID: <1990Dec21.200726.3608@odin.diku.dk>
Date: 21 Dec 90 20:07:26 GMT
References: <11323@pt.cs.cmu.edu> <1990Dec14.193111.11054@lpi.liant.com>
Sender: news@odin.diku.dk (Netnews System)
Organization: Institute of Computer Science, U of Copenhagen
Lines: 36

david@lpi.liant.com (David Michaels) writes:
>mbj@natasha.mach.cs.cmu.edu (Michael Jones) writes:
>> How can I write a macro which produces a character literal containing
>> a macro parameter?  I'd like to be able to write something like:
>>	#define chr(c) 'c'	/* Yes, this is incorrect */
>> which for
>>	chr(z)
>> produces
>>	'z'	

>ANSI C does not support any way do this, ...

More precisely, there is no way a strictly conforming program can do
this. As far as I can tell, a conforming implementation can allow
something like this:

	#define _chr(x,q) q##x##q
	#define chr(x) _chr(x,')

It has to be an implementation that treats an unmatched single-quote
as a preprocessing token by itself (the behaviour is undefined, see
section 3.1). Likewise, it must allow malformed tokens as intermediate
results during token pasting (undefined by 3.8.3.3). In such an
implementation, the code shown does not violate any constraints or
syntax rules. (The constraint in 3.1 talks about the lexical form of
preprocessing tokens converted in translation phase 7, not of their
derivation.)

But I don't think that such an implementation will become common. It
mucks up the scanner (which has to rescan the part of the line after
the unmatched quote), and it conflicts with the GNU C extension of
allowing newlines in character-constants and string-literals.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk