Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: #defines with parameters
Message-ID: <8986@smoke.BRL.MIL>
Date: 27 Nov 88 11:33:12 GMT
References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <8982@smoke.BRL.MIL> <14724@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <14724@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <264@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>[much not worth quoting]
>(It is, however, true that casting to whichever type is desired will
>patch things up and eliminate any difference between the two methods.)

Which is another reason the difference between "value preserving" and
"unsigned preserving" rules isn't very important: anyone who cares
will be using explicit casts to be sure the proper conversions occur.

>In article <8982@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>[parentheses in macro def/ref:]  Henry was mistaken about this.
>While he did not use dpANS phrasing, he did get the details right.

He may have.  However, I think Grandi interpreted him as saying that
white space was allowed before the ( in the DEFINITION of a function-
like macro, and I was responding to that.

	#define foo (x) ((x)+1)
	foo(z)
produces after substitution:
	(x) ((x)+1)(z)
whereas
	#define foo(x) ((x)+1)
	foo (z)
produces
	((z)+1)

X3J11 isn't proposing to change the way this has always worked.