TITLE: more on undefined behavior

[ Closing comments on the subject of undefined behavior with respect
  to expressions like "i = i++". -adc ]


PROBLEM: tomblin@ekfido.kodak.com (Paul Tomblin)

Actually, the standard clearly says that it's "undefined".  That means it
could execute it in either of the two methods you show, or it could decide to
delete all the files on your disk that end with the letters ".C", or it could
send email to bgates@microsoft.com, play hungarian nose-flute tunes, or
anything.


RESPONSE: seh@seh.codem.com (Stephen E. Halpin)

Interesting..  I only have K&Rs here, and it talks about the order of
evaluation being undefined, not the entire statement.  Please quote the
part of the C standard that says anything other than the order of
evaluation is undefined in this example.

If I have A and B, and they are to be executed once and only once, and I
say the order of evaluation within those constraints is undefined, it can
be A then B, or B then A.  It cannot be A and A, B and B, etc...


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 20 Sep 95

Sorry, that isn't correct.

ANSI/ISO C Standard, section 3.16, "Undefined behavior":
"Behavior ... for which this International Standard imposes no requirements.
Permissible undefined behavior ranges from ignoring the situation completely
with unpredictable results, to behaving during translation or program
execution in a documented manner characteristic of the environment ...
to terminating a translation or execution ... .
If a "shall" or "shall not" requirement that appears outside of a constraint
is violated, the behavior is undefined."

Section 6.3, "Expressions":
"Between the previous and next sequence point an object shall have its stored
value modified at most once by the evaluation of an expression."

The above sentence is not in a constraint section, and so violation means
undefined behavior. 


RESPONSE: clamage@Eng.Sun.COM, (Steve Clamage)

So why "undefined" instead of defining a complete ordering on expressions?
It allows compilers the freedom to generate efficient code. Given a
complicated expression with no sequence points, the compiler is allowed
to assume that the order of side effects doesn't matter, and so can do
things in the way that uses the least space and time. 


RESPONSE: kanze@lts.sel.alcatel.de (James Kanze)

[...]
do any real compilers actually generate better code
because of this freedom, and if so, how much better?


RESPONSE: clamage@Eng.Sun.COM, (Steve Clamage)

One compiler I worked on would reorder expressions to minimize use of
temps and registers. (Used registers had to be saved and restored, and
every extra register meant calling that function took longer by a push
and pop, other considerations aside.)

A simple example:
	n = k++ + f(j);

If you require left-to-right evaluation, you must do things in this order:
	save the current value of k
	increment k
	call f
	add the return value to the saved value of k
	store the result in n

Instead, the compiler would something like this:
	call f
	add the return value to the current value of k
	store the result in n
	increment k

Or possibly:
	store the value k in n
	increment k
	call f
	add the return value to n

The resulting code was smaller and faster, requiring no temps, and the
compiler really did look for and find this sort of improvement.