C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Unspecified versus undefined behavior Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Alf P. Steinbach Guest Posted: Thu Dec 16, 2004 6:19 pm    Post subject: Unspecified versus undefined behavior The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Note: this is an example quoted directly from the Holy Standard, which notes that it's unspecified behavior -- but in non-normative text. The long of this question: is the statement i = (i + 7) + (i = 5); // B unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Personal opinions: 1) Both (A) and (B) are merely unspecified behavior, because there's nothing possibly undefined involved, but, _formally_ it seems they are both actually undefined behavior (I'm unable to find where in the normative text the non-normative example is supported). 2) Statement (A) shouldn't really be even unspecified, but well-defined; the standard is UnGood in this respect. 3) Statement (B) should be unspecified. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top adeht Guest Posted: Fri Dec 17, 2004 4:42 am    Post subject: Re: Unspecified versus undefined behavior Alf P. Steinbach wrote: Quote: i = ++i + 1; // A i = (i + 7) + (i = 5); // B Both yield undefined behaviour (5p4). The same object gets modified twice without a sequence point between the modifications. In each of these lines, the only sequence point is the one at the end of the full expression (the semi-colon). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ron Natalie Guest Posted: Fri Dec 17, 2004 4:42 am    Post subject: Re: Unspecified versus undefined behavior Alf P. Steinbach wrote: Quote: 1) Both (A) and (B) are merely unspecified behavior, because there's nothing possibly undefined involved, but, _formally_ it seems they are both actually undefined behavior (I'm unable to find where in the normative text the non-normative example is supported). The double store case is onerous. In your contrived simple example it's quite possible for the compiler to emit either reasonably behaved (but indeterminate) or well defined code. However imagine the following; *i = *j + 7 + (*k = 5); where *i, *j, and *k all refer to the same object. The compiler may not be able to emit safe behavior for the above. Unless you want to further warp the standard by forcing additional sequence points in the experssion. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ron Natalie Guest Posted: Fri Dec 17, 2004 4:43 am    Post subject: Re: Unspecified versus undefined behavior Alf P. Steinbach wrote: Quote: Personal opinions: 1) Both (A) and (B) are merely unspecified behavior, because there's nothing possibly undefined involved, but, _formally_ it seems they are both actually undefined behavior (I'm unable to find where in the normative text the non-normative example is supported). The standard defines undefined behavior: undefined behavior behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. Further it describes expression behavior between sequence points: Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified.53) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. Your two expressions are clearly in the second sentence. The behavior is UNDEFINED. The first sentence says that for things like i++ + j++ (when i and j are distinct objects) that the order the increments get applied is unspecified (i may get incremented before j or vice versa, etc..). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Fri Dec 17, 2004 11:06 am    Post subject: Re: Unspecified versus undefined behavior On 16 Dec 2004 13:19:26 -0500, [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote in comp.lang.c++.moderated: Quote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Are we questioning the holiness of the standard, or the unholy stupidity of the question? Quote: Note: this is an example quoted directly from the Holy Standard, which notes that it's unspecified behavior -- but in non-normative text. The long of this question: is the statement i = (i + 7) + (i = 5); // B unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Personal opinions: 1) Both (A) and (B) are merely unspecified behavior, because there's nothing possibly undefined involved, but, _formally_ it seems they are both actually undefined behavior (I'm unable to find where in the normative text the non-normative example is supported). 2) Statement (A) shouldn't really be even unspecified, but well-defined; the standard is UnGood in this respect. Both statements have just plain old ordinary undefined behavior. Surely you read the text of paragraph 4 of section 5. You know, the paragraph that includes the example 'A' that you use in your post. But just in case you missed it, here is the normative text from the standard: "Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified.53) Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined." In both of your examples the value of 'i' is modified twice. Assuming 'i' is a scalar object (i.e., a built in type, not a user defined type with overloaded operators), they unless there is a sequence point between the two modifications, the behavior is undefined. And there is no intervening sequence point in either statement. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html> 3) Statement (B) should be unspecified. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Paavo Helde Guest Posted: Fri Dec 17, 2004 11:07 am    Post subject: Re: Unspecified versus undefined behavior [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote in news:41c1b0c8.96299828 @news.individual.net: Quote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Note: this is an example quoted directly from the Holy Standard, which notes that it's unspecified behavior -- but in non-normative text. The long of this question: is the statement i = (i + 7) + (i = 5); // B unspecified behavior, or is it undefined behavior, according to Strange question (as one should avoid both unspecified and undefined behaviour anyway). But: all of the "Holy Standard" is written keeping compiler implementors in mind. Just try to situate yourself in the position of writing (optimizing, of course) compiler implementor. You know that when you encounter a semicolon (ok, sequence point), all variables must have got a determined value. So you track changes to them and write them back in memory if changed (or maybe not, if you are clever enough...). In this particular case, it's obvious i is changed so a new value will get written back to the variable memory location. The value might involve adding of 7 or not, depending on how I implement the compiler. However, there is nothing illegal in both cases by itself, and there is no multithreading involved, so the value is get by normal arithmetic computations, in one way or another, and this is what the sandard calls "unspecified behaviour". IOW, the standard does not require the compiler implementors to follow an exact computation path in the middle of sequence points. As this might lead to different results in some situation, a term "unspecified behaviour" was invented. Yet IOW, the term "Unspecified behavior" has been invented in order to formalize the effects related to giving the implementations a license to do the optimizations in any order they want inbetween sequence points, and not vice versa. Yet yet IOW, your example is Unspecified Behaviour, by the Intent of Standard (regardless of what the Letter of Standard says) (IMSO). Best regards Paavo [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Fri Dec 17, 2004 11:10 am    Post subject: Re: Unspecified versus undefined behavior In both of your examples, the behavior is undefined. It's in 5/4, right before the example you cited. I agree that the words there are hard to understand, but I can't think of a better way to word it, and I don't think anyone else can either (many have tried). Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined. Each of your examples modifies the value of i twice, and neither one has a sequence point between them. Undefined behavior. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Old Wolf Guest Posted: Fri Dec 17, 2004 11:11 am    Post subject: Re: Unspecified versus undefined behavior Alf P. Steinbach wrote: Quote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? It's obviously undefined: you write 'i' twice (the ++i has side-effect of incrementing i, and the i = has side-effect of updating i), and there is not a sequence-point to be seen. Quote: 2) Statement (A) shouldn't really be even unspecified, but well-defined; the standard is UnGood in this respect. What do you think 'i' should be after this statement then? There's good reasons for both 2 and 3. The statement is equivalent to: - assign 2 to i - increment i with no sequence point. Quote: The long of this question: is the statement i = (i + 7) + (i = 5); // B unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? You are clearly assigning i twice, and there is no sequence point, so it seems pretty black and white to me. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Fri Dec 17, 2004 11:15 am    Post subject: Re: Unspecified versus undefined behavior * Ron Natalie: Quote: The standard defines undefined behavior [in e.g. §5/4]: Yes, that's the basis of the question. Your answer is equivalent to saying the standard is inconsistent here, that this is is a _defect_, and I think that requires more than just quoting a small part and simply asserting a given interpretation. Rephrased for 100% clarity: are the standard's own examples incorrect, as you maintain? -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Dec 17, 2004 1:30 pm    Post subject: Re: Unspecified versus undefined behavior In article <41c1b0c8.96299828 (AT) news (DOT) individual.net>, Alf P. Steinbach <alfps (AT) start (DOT) no> writes Quote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A In simple terms, if you write to an lvalue twice between sequence points you always have undefined behaviour. There are some other cases that do not include writing twice but the above guideline covers most of the territory. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Fri Dec 17, 2004 1:36 pm    Post subject: Re: Unspecified versus undefined behavior * Old Wolf: Quote: Alf P. Steinbach wrote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? It's obviously undefined: you write 'i' twice (the ++i has side-effect of incrementing i, and the i = has side-effect If it's obviously undefined, why does the standard say it's unspecified? Quote: 2) Statement (A) shouldn't really be even unspecified, but well-defined; the standard is UnGood in this respect. What do you think 'i' should be after this statement then? As long as we're clear on talking about hypothetical should with a less imperfect standard (a bit of context lost in quoting), I think a perfectly good way to _define_ such statements is (1) transform all prefix '++' and '--' to '+=' and '-=', respectively, (2) transform all assignment operators to simple assignments, yielding 'i = (i = i + 1) + 1', then (3) transform all simple assignments to calls of an assignment function, yielding 'asgn( i, asgn( i, i + 1 ) + 1 )', and now the rule for evaluation of arguments (sequence point before execution of function) yields in this case asgn( i, 1+1 ) = asgn( i, 2 ). Note that with this kind of definition my example B would still be unspecified (both formally and in-practice). Quote: There's good reasons for both 2 and 3. The statement is equivalent to: - assign 2 to i - increment i with no sequence point. No, I don't see that. I do see that it allowed by the current literal wording when ignoring what the standard itself says about this example. I don't see that there can be any real-world justification, do give? -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Fri Dec 17, 2004 1:40 pm    Post subject: Re: Unspecified versus undefined behavior * Jack Klein: Quote: On 16 Dec 2004 13:19:26 -0500, [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote in comp.lang.c++.moderated: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Are we questioning the holiness of the standard, or the unholy stupidity of the question? There are no stupid questions, only stupid answers. Quote: Note: this is an example quoted directly from the Holy Standard, which notes that it's unspecified behavior -- but in non-normative text. [snip] Quote: Surely you read the text of paragraph 4 of section 5. You know, the paragraph that includes the example 'A' that you use in your post. Dis you read my posting before attempting to answer? Did you _read_ the standard's text for example 'A' in §5/4? -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Fri Dec 17, 2004 1:47 pm    Post subject: Re: Unspecified versus undefined behavior Alf P. Steinbach wrote: Quote: The short of this question: assuming e.g. i == 0 as prior value, is the statement i = ++i + 1; // A unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? As others have pointed out, it is undefined behavior. Quote: Note: this is an example quoted directly from the Holy Standard, which notes that it's unspecified behavior -- but in non-normative text. So it does. I'd say that this is a defect in the standard -- the examples, while not normative, shouldn't lie. Quote: The long of this question: is the statement i = (i + 7) + (i = 5); // B unspecified behavior, or is it undefined behavior, according to the current text of the Holy Standard? Still undefined. Quote: Personal opinions: 1) Both (A) and (B) are merely unspecified behavior, because there's nothing possibly undefined involved, but, _formally_ it seems they are both actually undefined behavior (I'm unable to find where in the normative text the non-normative example is supported). I've heard vague suggestions that there might somewhere be a machine which supported parallel writes at different addresses, and that the language in the standard is to allow the compiler to generate parallel writes in such cases, even if it would cause the system to hang if the addresses were the same. (In the exact case you present, the compiler can easily recognize that parallel writes would be a no-no. But imagine something like *p = ++(*q) + 1, where p and q just happened to point to the same object.) I've never encountered such a machine, or even heard of one. I suspect that it is just a case that "unspecified" generally means out of a finite set of possibilities, and the authors felt it was too difficult to specify these possibilities. (Note that the problem becomes more complex if the object being modified is in an address expression, e.g. a[ i ] = i ++.) Quote: 2) Statement (A) shouldn't really be even unspecified, but well-defined; the standard is UnGood in this respect. I don't really see how anyone could disagree, but there is a long history behind it. Purportedly, it has to do with performance, although no one has ever shown an actual compiler where it would make a difference, and of course, Java JIT compilers often outperform C++ compilers, even though the order is strictly determined in Java. Note that the issue is even more critical in C++ than in C, since an exception may cause an expression to abort in the middle. Quote: 3) Statement (B) should be unspecified. Why, if A isn't? (IMHO, undefined or unspecified is an admission of an inability on the part of the authors. There should be only fully specified and implementation defined -- in other words, if the program compiles correctly without errors, I should be able to say exactly what it does on a given platform.) -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Old Wolf Guest Posted: Mon Dec 20, 2004 12:49 am    Post subject: Re: Unspecified versus undefined behavior [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: (IMHO, undefined or unspecified is an admission of an inability on the part of the authors. There should be only fully specified and implementation defined -- in other words, if the program compiles correctly without errors, I should be able to say exactly what it does on a given platform.) I disagree on the basis of efficiency. Consider: foo(a(), b(), c(), d(), e()) If you specify that the order is a,b,c,d,e and the machine uses a calling convention where it has to push e, then d, then c, etc. onto a stack (so that the called function pops parameters in order a,b,c,d,e), then the machine will have to not only generate extra code, but maybe even use up extra memory to store the temporary results of a(), b(), c(), d() until it pushes e() and can then push those results. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alf P. Steinbach Guest Posted: Mon Dec 20, 2004 10:38 am    Post subject: Re: Unspecified versus undefined behavior * Old Wolf: Quote: kanze (AT) gabi-soft (DOT) fr wrote: (IMHO, undefined or unspecified is an admission of an inability on the part of the authors. There should be only fully specified and implementation defined -- in other words, if the program compiles correctly without errors, I should be able to say exactly what it does on a given platform.) I disagree on the basis of efficiency. Consider: foo(a(), b(), c(), d(), e()) If you specify that the order is a,b,c,d,e and the machine uses a calling convention where it has to push e, then d, then c, etc. onto a stack (so that the called function pops parameters in order a,b,c,d,e), then the machine will have to not only generate extra code, but maybe even use up extra memory to store the temporary results of a(), b(), c(), d() until it pushes e() and can then push those results. Invalid logic because: if the order is unspecified by the standard then an implementation is free to choose any suitable ordering, including an ordering that depends on the calling convention. Invalid assumption because: computers don't have calling conventions. That does not mean that I agree with James on this particular issue (I don't, because a compiler may have to let the program invoke services that themselves have undefined behavior); it just means that the above argument is invalid, not meaningful. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.