short circuit evaluation

[Henry Spencer]

>     I can find no promise in K&R that bitwise expressions are not short
>     circuited even in the presence of side effects.  The ANSI draft
>     may have more to say.  In any case, I would advise not counting on
>     full evaluation.
> 
> K&R's note that ``The order in which side-effects take place is ...
> unspecified'' conspicuously fails to lend credence to this point of
> view.  Why should they unspecify the order, and not unspecify whether
> side-effects take place at all?

You are using what is sometimes known as the "Biblical Theory of Standards":
if the standard is by definition complete, an omission is highly significant
and may be taken to imply answers to questions that the standard does not
explicitly address.  In real life, "insufficient data" is a legitimate answer
to a question.  The fact is, K&R simply doesn't discuss the issue.  Your
reasoning does *suggest* that the *intent* was to require side effects, but
the fact remains that the document DOES NOT RESOLVE THE QUESTION.

In response to this, one can take one of two approaches.  One may assume that
all implementors will read the same message between the lines, and thus it
is proper to rely on side effects being present.  Alternatively, if one has
a bit less faith in the interlineal reading ability of implementors, one has
no choice but to assume that "no specification" means "unspecified".

> It seems to me that the idea of
> bitwise operators (or other operators lacking sequence breaks) not
> performing all their side-effects is so counterintuitive that it should
> be outlawed...

Why so?  I know of at least one language which explicitly says, right up
front, that no such assumptions are allowed and the compiler is free to
short-circuit anything it pleases.  This will affect programming style in
small ways (in my view for the better), but it's not an unthinkable heresy.
The language in question is Bliss, which has been quite successful in its
limited niche.

> ...Shall we perhaps leave unspecified whether
> 	*p++ = 0;
> increments p when the compiler can deduce that *p is already 0?

Whether one thinks this is legitimate depends on fine points of semantics;
you are trying to push the line of argument beyond the point where most
people would defend it.  The crucial observations here are that (a) the
value of the = operator is not being used, so its whole purpose is a side
effect, and (b) the postfix ++ operator likewise exists solely to cause a
side effect.  This isn't quite the same sort of animal as the situations
we were originally discussing.

> I find this perfectly acceptable, due to the above quote from K&R.  If
> you are accessing device registers code in C, you are expected to know
> what the compiler is going to do with your code...

Actually, the right solution to this is X3J11's "volatile" modifier for
types.  (They haven't handled it quite right, but the underlying idea is
correct.)  Then you do not need to be intimate with the compiler, because
you can explicitly tell the compiler "hands off this one".

> Are your cases of justifiable pornography sufficiently specific that
> they should appear in the standard?...

Probably not; I've never bothered pinning them down in detail.

> ...the standard must be precise here, and the ``so many complaints'' lead
> me to believe that the answer must be in favor of guaranteed execution of
> side-effects.

This is in fact what X3J11 has done.  I concede the practical necessity while
finding it aesthetically displeasing.
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry