Re: Benefit of not defining the order of execution

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.


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.


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. 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...


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.
.

Relevant Pages

  • Re: Benefit of not defining the order of execution
    ... execution is that the course of execution is not well defined. ... Deciding what to do about bugs ... the costs of such bugs, and the costs of finding or preventing ... evaluation doesn't carry any significant costs. ...
    (comp.lang.c)
  • Re: Demand That Microsoft Sell No Code Before Its Time
    ... Testing and fixing bugs costs money that can better be ... I've _never_ been charged by Apple or Microsoft for a bug fix. ...
    (microsoft.public.windowsxp.general)
  • Re: Static vs. Dynamic typing
    ... > So TDD might change the balance between costs and benefits of static ... ...there are situations in which - even with TDD - this isn't the case. ... Situations where the *target* execution platform is simply not ... the time between writing and executing can be long ...
    (comp.object)
  • Re: Jeffrey Lundgren execution: Killer Gives 8-Second Statement Before Execution
    ... Much more than it costs to incarcerate ... As for the actual execution costs, if anyone thinks that seventy bucks ... IMO, some crimes are so hienious in nature, the appeals process should be ... Someone with the mentality of a three year old wouldn't have the ...
    (alt.true-crime)
  • Re: Death penalty costly, unfair, and doesnt deter....
    ... offense, would you march happily off to the execution chamber, ... It costs exponentially less to incarcerate a murderer for life than it ... system can make an innocent person seem guilty of murder and then the ... innocent murder victims. ...
    (talk.politics.guns)