Re: Benefit of not defining the order of execution

On Wed, 18 Feb 2009 14:28:03 -0600, Stephen Sprunk
<stephen@xxxxxxxxxx> wrote:

Keith Thompson wrote:
Nate Eldredge <nate@xxxxxxxxxx> writes:
cri@xxxxxxxx (Richard Harter) writes:
(Think regression tests on log files.)

Huh?

Consider a program containing something like this:

double result = this() * that() + the_other();

Assuming that the three functions don't interact in any nasty ways
(depending on the same global variables, for example), the order of
evaluation shouldn't matter; result will get the same value for any of
the 6 possible orders. But suppose the functions contain trace
statements that (perhaps optionally) log information to a file. Then
the contents of the log can vary depending on the evaluation order,
and a testing scheme that looks for possible regressions by detecting
changes in the contents of the log will have problems.

Since the order of evaluation and thus the order of the log statements
(side effects that _do_ interact in a "nasty" way) is unspecified, your
testing scheme is broken if it assumes that your log statements are only
correct when in a certain order.

If you want them to appear in a particular order, make proper use of
sequence points to enforce that order. If you tell the compiler that
the order doesn't matter, which is what you're doing when you write code
such as above, then you shouldn't be surprised when it takes advantage
of that.

What you say is correct as far as it goes, but is not really to
the point, under the amiable assumption that this discussion has
a point. BTW in one sense it is a meta discussion since C is
what it is. On the other hand it is relevant because it involves
issues of programming practice that are peculiar to C.

The fundamental objection to not definining the order of
execution is that the course of execution is not well defined.
It can vary from environment to environment, from compiler to
compiler, and even from one release of a compiler to another.

Stephen say, in effect, if it matters to you, code in such a way
the course of execution is well defined. Well, yes, that is what
people attempt to do. In turn this brings in a series of little
"real world" problems. Here are some of them. The first is that
we need an additional suite of coding standards. Thus

merge(sort(left),sort(right));

is a no-no. There are other little gotchas. Does your QA guy
know what they all are? Do you? Is there a standard list some
where? If there is, is it comprehensive and without error?

Let us assume that we have an appropriate coding standard. Can
you guarantee that it is not violated anywhere. Yes, you have
code reviews, but they are not 100% reliable, particularly if you
are incorporating code written by other parties. Is there a
super-lint that will identify all of these violations? And so
on.

Remember, your regression tests can't tell you in advance that
there are variations. What they do is compare what you get today
with what you got yesterday. The variations don't show up until
you move your builds from one environment to another.

The point of all this is that there are costs to not defining the
order of execution along with the purported benefits.


Richard Harter, cri@xxxxxxxx
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
.

Relevant Pages

  • Re: Obstacles for Tcl/Tk commercial application development ?
    ... this is no problem: the compiler will refuse to ... previous message, it is impossible to check all execution paths, ... kilometers, which is clearly a type error. ...
    (comp.lang.tcl)
  • Re: FORTH: BEGIN as compile-time and no run-time?!?!?!?!? Help
    ... of the compiler for your own purposes. ... For example,] switches to compile mode and [to execute mode. ... execution tokens of its parts. ... whenever there is a 0 on the stack. ...
    (comp.lang.asm.x86)
  • Re: Attention Windows Users
    ... > So if the compiler were written to automatically include code for ... languages) that have built-in data integrity support, ... including software and hardware based protection for code execution of data. ...
    (rec.aviation.piloting)
  • Re: LEN_TRIM performance issue
    ... A long time ago in a Fortran 66 execution profiler ... it) was called FETE, Fortran Execution Time Estimator. ... out to be input to the compiler. ...
    (comp.lang.fortran)
  • Re: In-Out Parameters for functions
    ... > Why should buggy code work? ... As Ada stands now, it is perfectly ... the compiler cannot know whether particular ... then depending on the order of evaluation within an ...
    (comp.lang.ada)