Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: #defines with parameters
Message-ID: <14724@mimsy.UUCP>
Date: 26 Nov 88 22:48:39 GMT
References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <8982@smoke.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 55

>>In article <1988Nov22.170953.24489@utzoo.uucp> henry@utzoo.uucp
>>(Henry Spencer) writes:
>>>Definitions of parameterized macros ... have always been required to
>>>have the "(" immediately following the identifier.  The May draft
>>>standard requires that in the invocation, the "(" must be "the next
>>>preprocessor token", which basically means that white space there is okay.

Translation:

	#define	IDENT(a)	(a)

		IDENT   ( foo   )

is perfectly legal and produces `foo';

	#define	ANAME	(bar)

		ANAME(a,b)

produces `(bar)(a, b)' (syntactically a function call).

>In article <264@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
[much not worth quoting]

In article <8982@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>It would be nice if you checked what X3J11 had done before venturing an
>opinion.

Indeed.  However:

>If you're referring to the adoption of "value preserving" rules for type
>conversion, that is clearly a logical improvement over "sign preserving"
>rules, leading to surprising behavior less often, and turned out upon
>investigation to not break a significant amount of code already written
>according to sign-preserving rules.  Both variations were found in
>existing practice before X3J11 had to make a choice, and they chose the
>patently better set of rules.

All of this is true save the `clearly ... improvement', `surprising
...  less often', and `patently better' (which are all opinions).  The
problem with value-preserving rules is that predicting the type of of
an expression requires knowing something that cannot be known
portably:  it requires knowing whether the expanded (rvalue) type of an
lvalue actually contains more bits than the lvalue's type.  That is,
the type of the expansion of an `unsigned short' might be `unsigned
int' or `int', and there is no way to tell which.  (It is, however,
true that casting to whichever type is desired will patch things up and
eliminate any difference between the two methods.)

>[parentheses in macro def/ref:]  Henry was mistaken about this.

While he did not use dpANS phrasing, he did get the details right.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris