C Language, Odd trivia question involving && and ,

Micha Berg
#1 / 6

Odd trivia question involving && and ,

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

1-
E1 &&
E2,
E3;

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

--
Micha Berger

If nothing you try will work, try to fail.

Mon, 19 Oct 1992 02:17:09 GMT

Chris Tor
#2 / 6

Odd trivia question involving && and ,

Quote:

(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':

Quote:

> E1 &&
> E2,
> E3;

(vs)

Quote:

> 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)

Mon, 19 Oct 1992 14:13:19 GMT

Brian Westley (Merlyn LeR
#3 / 6

Odd trivia question involving && and ,

Quote:

>Do these pieces of source code produce significantly different object
>code?

1-

Quote:

> E1 &&
> E2,
> E3;

2-

Quote:

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

I found that many compilers{*filter*}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

Wed, 21 Oct 1992 00:29:13 GMT

Mark A Terribi
#4 / 6

Odd trivia question involving && and ,

Quote:

> >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{*filter*}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.

It's already been pointed out about five times, but here goes:

The comma operator has a LOWER precedence than the && . This means
that you must PARENTHESIZE.

E1 && ( E2, E3 );

should have the same effect as

if( E1 ) { E2; E3; }

Quote:

> 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.

If you don't know the rules, what business have you in trying to break them?

We had here a debate between the folks who always parenthesize because the
rules are too hard to learn and the folks who learn the rules rather than
hiding behind the parentheses. May I suggest that you join one of these
camps? Either would have protected you from this error and from the mortal
embarassment of discovering that you have accused perfectly innocent compilers.

And, in an Obfuscated C contest, from who-knows-what-other errors.

BTW, why aren't there Obfuscated LISP contests? Is it because Obfuscation
inheres in LISP?
--

(This man's opinions are his own.)
From mole-end Mark Terribile

Thu, 22 Oct 1992 15:53:29 GMT

Brian Westley (Merlyn LeR
#5 / 6

Odd trivia question involving && and ,

Quote:

>> >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{*filter*}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.
>It's already been pointed out about five times, but here goes:

Then why on earth are you posting this? Fun?

Quote:

> The comma operator has a LOWER precedence than the && . This means
>that you must PARENTHESIZE.

Yes; I DIDN'T post the original, unparenthesised code. I missed the
operator precidence bug. I made a mistake (gasp).

My main point was, EVEN WITH parentheses, many compilers{*filter*}up the
following expression:

Quote:

> E1 && ( E2, E3 );

Not all compilers do this right, which was my main point.

Quote:

>> 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.
>If you don't know the rules, what business have you in trying to break them?

I do know the rules; I just missed one lousy precidence error.
This translates to "doesn't know the rules" in your book, I suppose.

For your information, I've had a winning entry in the Obfuscated C code
contest for the last three years straight, and I intend to win again this year.
Still think I don't "know the rules"?
By the way, here is an excerpt from my winning entry from 1989:

...I do:

expr1 && expr2 && (expr3=etc);

which is the same as:

if (expr1 && expr2) expr3=etc;

A/UX on the Macintosh doesn't get this right; it evaluates ALL
expressions if they aren't in an assignment or conditional
statement. This might warrant a warning, since other compilers
may do this. I found MANY compilers botched:

expr1 && (expr2,expr3);

expr2 was OFTEN evaluated even if expr1 was false. I removed
such statements to make it more portable.

...see any errors in that?

Quote:

>We had here a debate between the folks who always parenthesize because the
>rules are too hard to learn and the folks who learn the rules rather than
>hiding behind the parentheses. May I suggest that you join one of these
>camps?

And may you go jump in the lake? Mark, your sarcastic attitude is
irritating and adds nothing to comp.lang.c

Quote:

>Either would have protected you from this error and from the mortal
>embarassment of discovering that you have accused perfectly innocent compilers.

No, Apple's compiler DID get this wrong:
i = 0;
i && (printf("bad\n"), 1);

...it printed out "bad\n". I've checked A/UX 2.0 and it's been fixed.
But the bug is there in A/UX 1.1.1, and some other compilers.

You seemed to ASSUME that A/UX "got it right", when, in fact, if
YOU HAD TRIED IT, instead of SHOOTING OFF YOUR MOUTH, you would have
found that A/UX, in fact, SCREWS IT UP ROYALLY.

This would have spared you the embarassment of discovering that your
have defended a perfectly guilty compiler.

The point I was trying to make was, even WITH proper parenthization,
there are compilers that get E1 && (E2,E3) wrong. I *am* from the
"fully parenthesize" camp, which is why I didn't catch the precidence
error.

---
Merlyn LeRoy

Wed, 04 Nov 1992 01:41:42 GMT