From: utzoo!decvax!harpo!eagle!mhtsa!alice!npoiv!hou5f!wsh Newsgroups: net.lang.c Title: Re: if bug in Ritchie C compiler Article-I.D.: hou5f.196 Posted: Thu Jan 27 09:12:49 1983 Received: Sun Jan 30 05:09:02 1983 ************************************************************************** I have just noticed a bug in the Ritchie C compiler (or at least an example of it being too smart for its own good)... ************************************************************************** We quote from the Gospel according to Kernighan and Ritchie (p. 185): "Otherwise the order of evaluation of expressions is undefined. In particular the compiler considers itself free to compute subexpressions in the order it believes most efficient, even if the subexpressions involve side effects. The order in which side effects take place is unspecified. Expressions involving a commutatiave and associative operator (*, +, &, |, ^) may be rearranged arbitrarily, even in the presence of parentheses; to force a particular order of evaluation an explicit temporary must be used." The lesson seems to be that the code cited in the original article is not portable (assuming that the side effect from foo () is expected), and that the Ritchie compiler is acting entirely correctly (if only because the C language specification specifically relieves the compiler of responsibility for any particular implementation). Here is a case of the code (rather than the compiler) being too smart for its own good (again, assuming that the code expects foo () to be executed). A reasonable way to get around this problem is to use the comma operator; the expression if (foo (), 0) has the desired effect, in a well-defined way. Willie Heck abi - holmdel npoiv!hou5f!wsh