Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!eos!aurora!labrea!decwrl!pyramid!prls!philabs!micomvax!zap!iros1!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: bitwise short-circuiting
Message-ID: <982@mcgill-vision.UUCP>
Date: 10 Mar 88 07:01:23 GMT
References: <4224@june.cs.washington.edu> <2303@umd5.umd.edu> <9130@ism780c.UUCP>
Organization: McGill University, Montreal
Lines: 28
Keywords: bitwise optimize

In article <9130@ism780c.UUCP>, news@ism780c.UUCP (News system) writes:
< Chris Torek writing about optimizing expressions like:
<	a = 0 & f();	(void) f(), a = 0	if (1 | g()) s1; else s2;
< [says that f() and g() can't be eliminated unless the compiler can
< determine they are side-effect-free]

< Chris, how do you justify the above assertion?  I just got my copy of
< the the proposed standard (11 Jan 88 version).  On page 51 the
< semantics of the bitwise & operator is defined. I quote:

<	[Usual arithmetic conversions happen]
<	[Result is bitwise AND of operands]

< I could not find any thing in the standard that requires evaluation
< of side effects of the operands if the result can be determined
< without evaluating the operands.

Oh no.  Someone tell us this isn't really so....please....?  This would
definitely violate the Principle of Least Surprise, particularly when
there's a constant operand that's a configuration macro or something of
that sort....  Take this to the extreme and you can throw away all
function calls whose results aren't used (and which take no pointer
arguments)!

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu