Re: C FAQ 3.1


In article <pan.2005.04.26.12.56.34.141000@xxxxxxxxxxxxxxx>, Lawrence Kirby <lknews@xxxxxxxxxxxxxxx> writes:
> On Tue, 26 Apr 2005 12:04:15 +0000, Stan Milam wrote:
> >
> > Because it would clear up a lot of confusion, specify exactly what the
> > behavior should be. I am convinced we have undefined behavior because
> > K&R were too lazy or in a hurry to specify exactly what should happen in
> > these now undefined cases.
>
> It is more likely because this freedom gives compilers extra scope for
> optimisation. On some architectured the natural calling sequence might
> favour left to right evaluation of arguments, on another ot might be right
> to left. Some optimisers might find advantages in other arrangements.

In fact, with modern processors, it's quite likely that the optimal
order of evaluation for some function calls will depend on what else
is happening in the surrounding code, so the order might be different
for different calls in a given TU.

With OOE processors and write-back memory caching, it's possible that
even the compiler doesn't know what order evaluation will actually
effectively take place. Should C compilers be forced to insert memory
barriers in code that evaluates function parameters, just so the
order of evaluation can be specified?

I suspect Stan's conviction is way off base, and both K&R and the
committee had excellent reasons for not defining what happens in
every situation.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Company Secretary Finance Manager
1) Half-grey haired executives.
2) Must be waist-deep in their field of activities.
3) Must be having the know-how and the do-how of the latest
developments in their respective fields.
-- from "Appointments Vacant" section of Business India
.

Relevant Pages

  • Re: Benefit of not defining the order of execution
    ... important to force a particular order of evaluation. ... order is unspecified as far as the language is concerned) forcing a specific order on compilers will certainly still leave people getting it wrong *and* will make some implementations less efficient. ... Another lack of a win is that you don't meet the expectations of the programmers who expect the other order. ... What your example shows is that there is actually no need to specify which side of the road all cars must drive on, since both cases can be accommodated; likewise, there is no need to specify in what order C compilers evaluate expressions, since all orders can be accommodated. ...
    (comp.lang.c)
  • Re: The annotated annotated annotated C standard
    ... No, precedence is not the same as evaluation, ... Where everyone did things the same way then that's what the Standard required. ... But since different compilers handled these cases in different ways, the Standard granted permission to continue so to do. ...
    (comp.programming)
  • Re: Benefit of not defining the order of execution
    ... order is unspecified as far as the language is concerned) forcing a specific order on compilers will certainly still leave people getting it wrong *and* will make some implementations less efficient. ... it can store them at increasing offsets from the stack pointer. ... Programmers who currently expect an order of evaluation, ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... >> arise in practical programming, ... > Undefined behavior is behavior for which the standard ... > the other cases result in undefined behavior. ... >> See my argument on compilers vs. person above. ...
    (sci.crypt)
  • Re: One last chapter to review! Last chance! One-day only!
    ... > I consider non-specified evaluation order to be a TERRIBLE idea. ... > I have, over the past year, been testing the compilers on various lisp ... > implementations with a random test generator. ...
    (comp.lang.lisp)