Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: Brain-dead Unix tutor needs quick help (-1)
Message-ID: <6700@brl-smoke.ARPA>
Date: Thu, 19-Nov-87 11:56:48 EST
Article-I.D.: brl-smok.6700
Posted: Thu Nov 19 11:56:48 1987
Date-Received: Sun, 22-Nov-87 01:30:43 EST
References: <387@cogen.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <387@cogen.UUCP> alen@cogen.UUCP (Alen Shapiro) writes:
>block about the reason ()s are used in preprocessor expressions like
>#define XXX (-1).

-1 isn't much of a problem.  A better example is
	#define XXX (a + b)
for which
	XXX * c
has different meaning from what it would have were the parentheses
omitted.

For similar reasons, usually the arguments of a macro should be
wrapped with parentheses in the macro definition:
	#define ZZZ(i,j) ((i) * (j))
to prevent surprises with usages such as
	ZZZ(a+1,b+1)

If you don't see what the issue is, try expanding the above macro
invocations both with and without parentheses in the definitions,
then apply the C operator precedence/associativity rules.