Re: [ECOS] Optimizations and bad code

[Jonathan Larmour <jlarmour at redhat dot com>]

Hi Doug,

Doug Fraser wrote:
> When I made the statement about the compiler emitting
> erroneous object code, I was only alluding to the
> fact that the C line in question contained three
> distinct post-increment operators, and the author
> of the original message claimed that after that line,
> the variable had only incremented by one. That is
> an error, as I illustrated in my ill formed response,
> even a simple comma operator should be able to handle
> three post-increments properly. Certainly, the time at
> which each individual increment is performed is
> undefined. All that matters is that they all complete
> before the closure, which is the semicolon that terminates
> both the evil source line being discussed or the simple
> comma separated triplett in my first reply. I quess
> ANSI C presriptivists would call that a 'checkpoint'.

The standard uses the term "sequence point" :).

You assume that post-increments are in some way cumulative. That isn't
necessarily so. The comma operator is different because it is explicitly
defined that the comma is a sequence point. But if you pretend for a moment
that it isn't, then you can say that i++ is the same as (i=i+1,i-1).

So
a[i++] + (a[i++]<<1) + a[i++]

is the same as:

a[(i=i+1,i-1)] + a[(i=i+1,i-1)]<<1) + a[(i=i+1,i-1)];

with the only sequence point being at the end. Written out like this you
can hopefully see now that with multiple side effects like this the problem
is "when do you read i". It is only at sequence points that "all side
effects of previous evaluations shall be complete and no side effects of
subsequent evaluations shall have taken place" (according to the standard).
Because the sequence point is at the end, the value of i between the
previous sequence point and this sequence point can be anything from i to
i+3. And in the absence of any further sequence points, it's not defined
which.

And when using the comma operator (for real), there is a sequence point
each time, so that's different.

> You are right though, that badly formed code is a bad thing.
> It trips up developers when the compiler does something 'odd',
> and worse, it trips up maintainers that follow them later.

The classic way to make mistakes like the above is to pass in an expression
with side effects to a macro, and that can be done virtually undetectably.
I would hope the compiler would warn.
 
> My favorite quote on code complexity came from a colleague
> some years ago when I worked at Bell Labs. We were having
> a discussion at a code review on how one particular module
> could be greatly simplified, and her response was:
> 
> "Then anybody off the street could understand it."
> 
> The team leader replied, "Exactly!"

Heh. If anybody could understand it we'd be out of a job ;-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/