428,558 Members | 1,399 Online
Need help? Post your question and get tips & solutions from a community of 428,558 IT Pros & Developers. It's quick & easy.

# Sequence points

 P: n/a In a footnote in the c99 standard the following is labeled as undefined: a[i++] = i; And in the second clause of section 6.5 the following is stated: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored. 70)" So my question is, how do they derive undefined behaviour from "a[i++] = i;" ? With, a[i++] = i; this is one expression and there is only one sequence point here, ';'. 'i' has its value modified only once and that is in the subscript operator to designate which object the value of 'i', on the right side of the assignment operator, will be stored at. But, I am guessing I am missing something here. So if anyone could enlighten me it would be much appreciated :) Also, what is the difference between unspecified behaviour and undefined behaviour? The standard attempts to make a distinction between the two in Annex J but my dictionary gives the same definition for "unspecified" and "undefined" so I fail to see how they can be used to describe certain things as though they were different. Nov 13 '05 #1
4 Replies

 P: n/a j wrote: In a footnote in the c99 standard the following is labeled as undefined: a[i++] = i; And in the second clause of section 6.5 the following is stated: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored. 70)" So my question is, how do they derive undefined behaviour from "a[i++] = i;" ? With, a[i++] = i; this is one expression and there is only one sequence point here, ';'. 'i' has its value modified only once and that is in the subscript operator to designate which object the value of 'i', on the right side of the assignment operator, will be stored at. But, I am guessing I am missing something here. So if anyone could enlighten me it would be much appreciated :) It's the "furthermore" part that bites you here. The `i' on the right-hand side retrieves the value stored in the variable `i', correct? And is this retrieval for the purpose of determining what new value to store into `i'? No, it is not: the value retrieved is intended to be stored somewhere in the `a' array (but, because of U.B., there's no telling what might actually happen). So the right-hand-side use of `i' falls afoul of the "furthermore," and you've got trouble. Why the strange restriction? Because the Standard allows the side-effect of incrementing `i' to occur *anywhere* between the sequence point prior to this statement and the sequence point at the end. It might be the very first thing that happens, it might be the very last, it might even happen in parallel with other activities. That being the case, there's just no way to say what value the right-hand-side evaluation of `i' should produce, or even whether it *can* produce a meaningful value (think of 32-bit `long' on an 8-bit machine, where the operation of storing the new value might take several cycles). Of course, this "fuzziness" about the value doesn't extend to the `i++' on the left-hand side, if used in isolation. This sub-expression is required to yield the old value of `i', but the compiler can indulge in whatever sleight-of-hand it feels like to get this to occur. For example, it might rewrite the sub-expression as `(a - 1)[++i]' if that leads to smaller or faster code. There's just no telling when (between one sequence point and the next) the incrementation side-effect will become "visible" to the world at large. Also, what is the difference between unspecified behaviour and undefined behaviour? The standard attempts to make a distinction between the two in Annex J but my dictionary gives the same definition for "unspecified" and "undefined" so I fail to see how they can be used to describe certain things as though they were different. The Standard uses these words (and others) in a restricted and specialized sense because it needs more precision than is afforded by ordinary English. Other fields of discourse also use ordinary words in specialized ways -- for example, a "field" means rather different things to farmers, mathematicians, and footballers. In Humpty Dumpty's phrase, "When I use a word, it means exactly what I wan it to mean-- neither more nor less. It's a question of who's to be master, that's all." The Standard gives its particular definitions of these terms in sections 3.4.3 and 3.4.4, and you're welcome to ponder them there. Informally, - For "unspecified" behavior, the Standard enumerates all the permissible behaviors but doesn't say which of them might actually occur. You know you'll get either A or B or C, but not which -- and you might not get the same one next time, either. However, you won't get X. - For "undefined" behavior, the Standard specifies nothing at all. You cannot assume the result will be A, B, or C; anything at all could happen: you could get X, or Y, or the program could halt, or chocolate pudding could ooze from your keyboard -- or, of course, you could get A. Nothing prevents a particular implementation from specifying what the Standard leaves unspecified or defining what the Standard leaves undefined. A particular implementation might specify that all operands are evaluated left-to-right, which would make the behavior of `a[i++] = i' perfectly well-defined -- but only for that implementation, of course. Another might actually define `a[i++] = i' as causing demons to fly from your nose -- and much as I might admire their technical expertise, I have absolutely no desire to meet the people responsible for that outcome ... -- Er*********@sun.com Nov 13 '05 #2

 P: n/a Shill wrote in message news:bf***********@biggoron.nerim.net... Another might actually define `a[i++] = i' as causing demons to fly from your nose -- and much as I might admire their technical expertise, I have absolutely no desire to meet the people responsible for that outcome ... I've read the demon-from-nose bit several times in this group. Pray tell, which compiler might pull off such an engineering feat? If Bill Gates has really made a pact with the Devil, then perhaps VC is our closest bet? I don't know about Bill, but Mother Nature has achieved this long ago. Ask any allergy sufferer. :-) -Mike Nov 13 '05 #3

 P: n/a j wrote: In a footnote in the c99 standard the following is labeled as undefined: a[i++] = i; Please review the FAQ list: http://www.eskimo.com/~scs/C-faq/top.html Also, what is the difference between unspecified behaviour and undefined behaviour? The standard attempts to make a distinction between the two in Annex J but my dictionary gives the same definition for "unspecified" and "undefined" so I fail to see how they can be used to describe certain things as though they were different. And again, see the FAQ. Brian Rodenborn Nov 13 '05 #4

 P: n/a On Wed, 23 Jul 2003, Eric Sosman wrote: j wrote: Furthermore, the prior value shall be read only to determine the value to be stored. 70)" It's the "furthermore" part that bites you here. The `i' on the right-hand side retrieves the value stored in the variable `i', correct? And is this retrieval for the purpose of determining what new value to store into `i'? No, A perverse interpretation would even say that a = i++ has undefined behavior, because the prior value of i is accessed to determine *two* values to be stored into i and a respectively, without an intervening sequence point. Tak-Shing Nov 13 '05 #5

### This discussion thread is closed

Replies have been disabled for this discussion.