[comp.lang.c] Odd trivia question involving && and ,

aj-mberg@dasys1.uucp (Micha Berger) (05/03/90)

Do these peices of source code produce significantly different object
code?

1-
	E1 &&
		E2,
		E3;

2-
	if (E1) {
		E2;
		E3;
	}


-- 
					Micha Berger
					mberger1%tasha@graf.poly.edu

If nothing you try will work, try to fail.

chris@mimsy.umd.edu (Chris Torek) (05/03/90)

In article <1990May2.181709.8988@dasys1.uucp> aj-mberg@dasys1.uucp
(Micha Berger) writes:
>Do these peices of source code produce significantly different object
>code?

The answer to the question you asked is `yes', but the answer to the
question you probably meant to ask is `no':

>	E1 &&
>		E2,
>		E3;

(vs)

>	if (E1) {
>		E2;
>		E3;
>	}

Since `&&' binds tighter than `,', the first fragment is equivalent to

	if (E1) E2;
	E3;

If you change the first fragment to

	E1 && (E2, E3);

then the answer is `no, not unless you try to get the value of the
exression'---at least, not in any decent compiler.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris

merlyn@digibd (Brian Westley (Merlyn LeRoy)) (05/04/90)

aj-mberg@dasys1.uucp (Micha Berger) writes:
>Do these pieces of source code produce significantly different object
>code?

1-
>	E1 &&
>		E2,
>		E3;

2-
>	if (E1) {
>		E2;
>		E3;
>	}

I found that many compilers screw up expression (1);
E2 would often be evaluated even when E1 is false.
They SHOULD produce the same results, but look out
when you operate in the real world.
A/UX (Apple's Unix) even screwed up E1 && E2 as a standalone
statement (it only short-circuited the && in if(), etc, statements).

I found this out as part of my obfuscated C code entry for last year.
----
Merlyn LeRoy