From:	Erik Max Francis <max AT alcyone DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: [Q] expression evaluation order
Date:	Mon, 11 Aug 1997 21:49:14 -0700
Organization:	Alcyone Systems
Lines:	80
Message-ID:	<33EFEB4A.4CB33BD3@alcyone.com>
References:	<5sbb1h$kvr$1 AT newton DOT pacific DOT net DOT sg> <5sd0pd$k66$1 AT gte1 DOT gte DOT net>
	<33EA9D38 DOT 31561027 AT alcyone DOT com> <5sfpqj$rdk$1 AT gte2 DOT gte DOT net>
	<33EBB438 DOT 32888436 AT alcyone DOT com> <33EEC7BF DOT 1570 AT pentek DOT com>
NNTP-Posting-Host:	newton.alcyone.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Charles Krug wrote:

> The original question that started this round:
> 
> if (first() && second() && third())
>         (etc)
> 
> How critical is your application, and how much interaction is there
> between the functions in question?

Are you _seriously_ suggesting that you're scared of using _basic C
language features_ because you're afraid there might be compiler bugs?  Is
that _really_ how you approach all of your programming projects -- using
only what you deem to be the most simple language features available?

> Of course, I live a rather charmed existence.  I've never had to read
> the 30 page section of a compiler manuel listing, "Differences from
> Traditional C", "Differences from ANSI C", and "Differences from K&R
> C."  Yep, since ANSI says it. It must be so.
	... and then a sad drug war reference ...

Uh, what?  ANSI indicates that && and || are short circuiting.  That means
that if you have an ANSI compiler that doesn't do it properly, you send in
a bug report and they fix it.  _Particularly_ considering that I have
_never_ encountered a compiler -- much less an ANSI compiler -- that does
not support short circuiting -- a feature that has been in C since
traditional C, much less K&R or ANSI -- I hardly think that this should be
a programmer's biggest concern.  A far better concern would be to make
sure that the code _you_ write works properly.

> Broken && || evaluation isn't something you'd catch every time, unlike,
> say, the increment operator.  How often do we write logicals that rely
> on complex function interactions, rather than something that works out
> to:
> 
> if ((a==1) && (b==1) && (c==1))

So you're saying that between the two possibilities:

    if (first() && second() && third()) return false;

and

    bool a = first(), b = second(), c = third();

    if (a && b && c) return false;

You're concerned that the first may not work because of a buggy compiler
implementation?  I'd be much more concerned that the functions involved
don't do what you think they do!

And since you're on the subject, are you sure that an expression (a)
evaluates in a logical context to true if nonzero and false if zero?
Sure, it's been part of C since early implmentations, but who knows!

    if (a == true && b == true && c == true) return false;

But still, who knows if the compiler implementor got operator precedence
right!  We'd better write 

    if ((a == true) && (b == true) && (c == true)) return false;

Hopefully my sarcasm is showing through.

> If that works correctly, as it likely does, it might not occur to most
> of us to look for trouble in the evaluation of the more complex case,
> given in the original post.

If a short circuiting example doesn't work, it would take you about twenty
seconds to discover this with a source-level debugger.  Of all the things
in the world a programmer should worry about, this is about as low on the
list as it gets.

-- 
       Erik Max Francis, &tSftDotIotE / email / mailto:max AT alcyone DOT com
                     Alcyone Systems /   web / http://www.alcyone.com/max/
San Jose, California, United States /  icbm / 37 20 07 N  121 53 38 W
                                   \
   "Love is not love which alters / when it alteration finds."
                                 / William Shakespeare, _Sonnets_, 116

- Raw text -