From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Doug Fraser , eCos discussion Subject: Re: [ECOS] Optimizations and bad code Date: Tue, 24 Jul 2001 06:23:00 -0000 Message-id: <3B5D76BC.E76AC01D@redhat.com> References: X-SW-Source: 2001-07/msg00735.html 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/