Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c
Subject: Re: X3J11 meeting notes
Keywords: ANSI C standard, parens honored, macros
Message-ID: <2043@ttrdc.UUCP>
Date: 18 Dec 87 19:31:15 GMT
References: <6829@brl-smoke.ARPA> <406@mn-at1.UUCP> <6852@brl-smoke.ARPA> <13899@think.UUCP>
Organization: AT&T, Skokie, IL
Lines: 52

In article <13899@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> The biggest problem I see with this requirement [that C honor parenthesis
> groupings in expression evaluation] is due to macros.  In
> order to implement macros that expand into arithmetic operations and
> guarantee that they are well behaved it is necessary to use a level of
> parentheses, e.g.
> 
> #define one_more_than(x) (x + 1)
> 
> If the parentheses are omitted, as in
> 
> #define one_more_than(x) x + 1
> 
> then things like this happen:
> 
> 	(2 * one_more_than(3)) != (one_more_than(3) * 2)
> 
> This standard change effectively disallows many optimizations of
> expressions that make use of macros.

This would be a better example if instead of
	... one_more_than(2) ...
you had said
	int i;
	...
	i = <some non constant expression which evaluates to 2>;
	...
	... one_more_than(i) ...

In the first case, using the parens around (x + 1) would not harm the
compiler's ability to optimize, because the "as if" rule would allow the
constants to be folded in actual evaluation.  In the second case, this
could conceivably cripple optimization of macros.

This could be kludged around however by making the C compiler ignore one level
of parens (insofar as they require the compiler not to regroup associative
and commutative operators) which come from macros.  The macro would need
to double-paren an expression, e.g., ((x + 1)), to ensure the non-regrouping
evaluation behavior.  In a system with a separate preprocessor and compiler,
this could be done by having the preprocessor turn all single parens in
expressions into double parens (except those coming from macros and those
around a function call or declaration argument list) and having the actual
compiler recognize this special meaning of double parens versus single parens.

Can anyone come up with a reasonable example of a macro that would be badly
hurt in efficiency if the proposed rule to honor parentheses (except where
the result would be the same) were implemented?
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Computer Systems Division |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|