Re: Benefit of not defining the order of execution

On 20 Feb 2009 11:16:31 -0800, Tim Rentsch
<txr@xxxxxxxxxxxxxxxxxxx> wrote:

cri@xxxxxxxx (Richard Harter) writes:

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

[... order of evaluation and statements in a log file ...]

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.

Here I'm confused. Do you mean that order-of-evaluation issues
come up only with C? Or are you talking about something else?
I'm not sure what you're referring to.

C has many features that create order-of-evaluation and undefined
behaviour issues. Thus, pointers create aliasing issues.
Assignment is an operator rather than a statement; increment and
decrement prefix and postfix have assignment properties, in some
cases expressions are guaranteed to be evaluated left to right,
e.g. shortcut booleans, and other cases not. More than that,
many standard C idioms exploit these features.



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.

You say that like it's automatically a bad thing. I believe
it's actually a good thing, for reasons that I've tried to explain.

And I disagree with your rationales. One could argue that a
language that properly supported indeterminancy would be a good
thing. C is not that language. Indeterminancy in C is a series
of hacks, historical artifacts and micro optimizations.



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.

No development process is perfect, partly because it's too
hard to make a perfect process, but also because a perfect
process is too expensive. Deciding what to do about bugs
caused by order-of-execution dependencies means comparing
the costs of such bugs, and the costs of finding or preventing
them, against the costs of other kinds of bugs, and the
costs of finding or preventing those bugs. Do you have
some data that suggests the ratios for OOE bugs are
significantly worse than those for other kinds of bugs?
If so I'm sure everyone would welcome it being reported.


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.

You seem to take it as true, just as a matter of course, that testing
won't be effective in discovering problems with order-of-evaluation
dependency.

That's a rather odd thing to say. I wasn't talking about that at
all.

It's true that a different kind of testing needs to be
done to discover such problems, but I just don't think it's that hard
to set up a C-to-C translator to "stress test" different evaluation
orders and put that into the QA process. Is one of these out there
in the open source community? I wonder...

I'm skeptical about the feasibility. One might be able to
construct such a translator, but designing an appropriate test
suite is quite another matter.



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

I don't think there's any disagreement on that point; the harder
question is, what are the costs and benefits on each side of the
issue? My difficulty with some of the pro-determinism statements
(without meaning to attribute them to any particular person) is that
they seem to imply (at least, sometimes) that a defined order of
evaluation doesn't carry any significant costs. If I think they do
carry significant costs, what am I to say to someone who says "No,
you're wrong, they don't carry any significant costs", and don't say
anything more? This question is somewhat unfair since such a blunt
statement hasn't been made; however, I think it does accurately
reflect the frustration that some people (and to be fair, on both
sides) have been feeling.

From the other side of the fence, the supposed costs of defined
order of evaluation, while real, are overstated whereas the costs
of indeterminancy are simply ignored.

Be that as it may, I was impressed with your long posting; I will
respond when I get the chance.



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