Not "well-defined" is the proper terminology.
No. You might be right if we were talking about "proper use" in English as a spoken language, but "undefined behavior" is a technical term defined by the C and C++ ISO standards.
A glimpse of undefined behavior in C
21–30 of 67 posts
Re: A glimpse of undefined behavior in C
#22Sequence points are an interesting topic on their own. http://stackoverflow.com/a/4176333
I think they are the only thing relevant in the article. The introductory example is just one example of how not knowing about sequence points leads to bugs. There are many more and it makes for a much more interesting read to first learn about sequence points and then applying that knowledge to various examples.
This article goes about it the wrong way.
Re: A glimpse of undefined behavior in C
#23Yes, don't change the same variable in multiple places in the same statement in C.
In some cases the behaviors is well defined, if there are sequence points between the assignment, but I would rather keep my code simple.
Re: A glimpse of undefined behavior in C
#24Knowing how exactly sequence points work might be an advanced topic, but I am not sure I'd hire a junior C/C++ programmer if he has not heard of sequence points. If somebody has, then he clearly won't do something like this code. I am not 100% sure in how they work either (haven't programmed C for 4 years), so I just avoid these kind of unnecessary complications in the code, if not for myself, then for the guy who co…
I am not 100% sure in how they work either (haven't programmed C for 4 years), so I just avoid these kind of unnecessary complications in the code
Hear, hear. I am considered the "language lawyer" of my embedded group and often get asked questions about C minutiæ. It isn't uncommon that my answer is "I don't know how that works, because I would never write something that requires an answer to that".
Modern compilers are blind to shorthands etc.; the only useful knowledge about "C" (really C compiler & hardware) minutiæ relates to (a) how to convince the compiler to optimize certain high-level constructs (e.g. loop unrolling), (b) how to convince the compiler to emit certain low-level constructs (e.g. SIMD instructions), and (c) how the hardware behaves (e.g. the cache model). Generally anything else – you can rewrite it so you don't have to think too hard about how C works.
EDIT: Understanding type promotion is an exception to this. The integer type hierarchy is unfortunately (a) deeply baked into C and (b) mostly brain-dead – C mostly conflates physical integer width with modular arithmetic and provides no non-modular integer types, often leading to subtle software bugs (see last week's story about binary search).
EDIT: So is understanding const-ness. At least you can ignore this if you don't get it (or if C doesn't, as is the case with certain nested const types).
Re: A glimpse of undefined behavior in C
#25Why? What reason could there possibly be that such well known, gaping holes in the standard have persisted for all these years and multiple standard revisions?
C90, C99, C11 and now C14... If performance or backward compatibility is a concern, surely an optional macro like __STDC_STRICT__ could be suggested in the standard with clear expectations that could be relied on.
Re: A glimpse of undefined behavior in C
#26Earlier quoted context omitted.
exactly. This is precisely to spec; and I got the answer of 60 immediately on looking at the code.
This is incorrect; it is undefined behavior according to the spec: http://www.reddit.com/r/programming/comments/1rrefp/a_glimps...
ah, sorry, I'm stuck in C[whatever it was I learned in high school]
Re: A glimpse of undefined behavior in C
#27Why? What reason could there possibly be that such well known, gaping holes in the standard have persisted for all these years and multiple standard revisions? C90, C99, C11 and now C14... If performance or backward compatibility is a concern, surely an optional macro like __STDC_STRICT__ could be suggested in the standard with clear expectations that could be relied on.
That's a reasonable question. It's a shame this comment gets downvoted instead of the various people falling all over themselves to show off how smart they are by posting incorrect guesses about how undefined behavior doesn't matter.
Here's a good article that addresses the question "Why have undefined behavior?"
http://blog.regehr.org/archives/213
This one linking to the above is also worth reading:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
Re: A glimpse of undefined behavior in C
#28Knowing how exactly sequence points work might be an advanced topic, but I am not sure I'd hire a junior C/C++ programmer if he has not heard of sequence points. If somebody has, then he clearly won't do something like this code. I am not 100% sure in how they work either (haven't programmed C for 4 years), so I just avoid these kind of unnecessary complications in the code, if not for myself, then for the guy who co…
Just FYI for readers, the term "sequence point" has been deprecated in C++11. There is now a richer notion of operations being sequenced before/after each other or unsequenced. This motivation for this was to improve C++'s memory model in the face of concurrency. (It does not change the results of this discussion, though :) )
More info here: http://blogs.msdn.com/b/vcblog/archive/2007/06/04/update-on-... and here http://en.cppreference.com/w/cpp/language/eval_order
Re: A glimpse of undefined behavior in C
#29Lesson I took away:
The ++ operator should be deprecated except when it's the only operation on that line.
Re: A glimpse of undefined behavior in C
#30The way I learned that in C a long time ago was "post increment" was "post statement increment".
it's a little weirder though. int main(int argc, char argv) { int a = 0; printf("%i %i %i\n", a, a++, a++); } will give "0 0 1" (gcc 4.2.1), the increment "shouldn't" happen until after the ; if you're going with post statement. I think your rule would expect "0 0 0" with a being 2 after the printf. BUT! you get a warning, so that's nice.
The issue here is that the order of function argument evaluation is undefined. If the commas weren't inside of a function call, they would result in sequence points. So, this would be well defined:
int a = 0, b, c;
b = a++, c = a++;