Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 08 May 2012 05:28:56 -0500 Message-ID: <4FA8F568.4D99@mindspring.com> Date: Tue, 08 May 2012 06:28:56 -0400 From: pete Reply-To: pfiland@mindspring.com Organization: PF X-Mailer: Mozilla 3.04Gold (WinNT; I) MIME-Version: 1.0 Newsgroups: comp.lang.c Subject: Re: List of undefined behaviour and other sneeky bugs References: <61f319f8-323e-41ec-938a-8062d532aa6a@a5g2000vbc.googlegroups.com> <4FA35A2E.6B0B@mindspring.com> <4FA896E6.B8E@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 89 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.156.228.178 X-Trace: sv3-xjvfIO75RkLbURFwWLN5cRpMqCDLZTHdoBCkyG4z6Ca7tyvATSI9PG0kaMz0gkQ2wGA16R5xUz/z2a7!WwUG7Ibsaxl/WMfKz8TaYGgdDDFHd8bKeV+LKwUHo0LU9fWaji2vkqa6hqDtSGw7LJmX7aR55Ftf!ZcuxkLGBUYk= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4337 Xref: csiph.com comp.lang.c:20496 Tim Rentsch wrote: > > pete writes: > > > Tim Rentsch wrote: > >> > >> pete writes: > >> > >> > John Reye wrote: > >> >> > >> >> 1) > >> >> a[i] = i++; > >> >> > >> >> http://c-faq.com/expr/evalorder1.html > >> >> > >> >> So this attempt at optimisation is wrong: > >> >> > >> >> int i; > >> >> int a[10]; > >> >> for (i = 0; i < sizeof(a); ) > >> >> a[i] = i++; /* set a to {1, 2, 3, ...} */ > >> >> > >> >> Correctly optimized, it should be: > >> >> for (i = 0; i < sizeof(a); ) > >> >> i = a[i] = i+1; /* set a to {1, 2, 3, ...} */ > >> > > >> > No. That's wrong. > >> > Concerning > >> > i = a[i] = i+1; > >> > Assignment, is not a sequence point. > >> > The above code does not say whether the value of (i+1) > >> > is stored first in (a[i]) or in (i). [snip alternative] > >> > >> The behavior of > >> > >> i = a[i] = i+1; > >> > >> is well-defined. I refer you to 6.5.16 p3 in N1570, specifically > >> the second-to-last sentence. By the time the store into 'i' > >> commences, the value (lvalue) computation of 'a[i]' has already > >> completed, because it is sequenced before delivering the value > >> to be stored into 'i'. > >> > >> The stores to 'i' and 'a[i]' may happen in any order, but the > >> lvalue 'a[i]' must be determined before any store into 'i'. > > > > I don't see where it says what you say that it says. > > > > Concerning (a[i] = i+1), > > "the value of the left operand after the assignment" > > can be determined before the assignment > > and without knowing which array element a[i] refers to. > > > > You don't have to know which array element a[i] refers to, > > to know > > what the value of (i+1) converted to whichever type (a[i]) has, > > is. > > > > n1570 > > 6.5.16 Assignment operators > > Semantics > > 3 An assignment operator stores a value > > in the object designated by the left operand. > > An assignment expression has > > the value of the left operand after the assignment,111) > > but is not an lvalue. > > The type of an assignment expression > > is the type the left operand would have after lvalue conversion. > > The side effect of updating the stored value of the left operand > > is sequenced after the value computations of the left > > and right operands. > > The evaluations of the operands are unsequenced. > > The missing piece (which I should have mentioned before - > sorry about that) is 6.5 p1, last sentence: > > The value computations of the operands of an operator are > sequenced before the value computation of the result of > the operator. > > So the lvalue 'a[i]' must be computed before there is a value > (produced by the intermediate '=' operator) to store into 'i'. I think that you may be right. I also made an obsolete statement elsewhere in this thread about the postfix increment operator. -- pete