bob wrote:If you think about that for a minute, how can those be different? It would seem to me that "undefined" == "unspecified".
The answer to your question is in the C standard on page 3.
So, basically...
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
What a wonderful "specification" that turns into...
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible". Apple should have read that. "Do the right thing" does not mean "abort" when there is a better option available.
bob wrote:If you think about that for a minute, how can those be different? It would seem to me that "undefined" == "unspecified".
The answer to your question is in the C standard on page 3.
So, basically...
unspecified. Do whatever you want, just so you document it.
Almost. It is not a requirement to document unspecified behavior.
undefined. Do whatever you want, but don't document it.
Almost. It is not a requirement not to document undefined behavior.
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible". Apple should have read that.
I can't find where it says that. Not in the working draft that Ronald links to, and not in the approved standard itself. Can you give the reference?
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
No.
Unspecified behavior means there are a limited number of possibilities and the compiler is free to choose any one of them. A program that exhibits unspecified behavior must still have the semantics specified by the abstract machine in so far as it is specified. So your code should not depend for its correctness on a particular order in which function arguments are evaluated, because different C99-compliant compilers may evaluate them in a different order.
Undefined behavior means the standard does not impose any requirements whatsoever. Not on the program's compilation (the compiler may fail on it), not on the program's execution (it may delete all your data).
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
A compiler does not have to map C constructs to your hardware the way you expect it to do. If the compiler is able to detect that a branch of your code when executed leads to integer overflow, the compiler may decide to optimise that whole branch away..
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible".
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
No.
Unspecified behavior means there are a limited number of possibilities and the compiler is free to choose any one of them. A program that exhibits unspecified behavior must still have the semantics specified by the abstract machine in so far as it is specified. So your code should not depend for its correctness on a particular order in which function arguments are evaluated, because different C99-compliant compilers may evaluate them in a different order.
Undefined behavior means the standard does not impose any requirements whatsoever. Not on the program's compilation (the compiler may fail on it), not on the program's execution (it may delete all your data).
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
A compiler does not have to map C constructs to your hardware the way you expect it to do. If the compiler is able to detect that a branch of your code when executed leads to integer overflow, the compiler may decide to optimise that whole branch away..
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible".
Thanks Miguel, that is indeed a very clear explanation !
These three variations on ``not precisely defined by the standard'' are defined as:
implementation-defined: The implementation must pick some behavior; it may not fail to compile the program. (The program using the construct is not incorrect.) The choice must be documented. The Standard may specify a set of allowable behaviors from which to choose, or it may impose no particular requirements.
unspecified: Like implementation-defined, except that the choice need not be documented.
undefined: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended.
Note, too, that since the Standard imposes absolutely no requirements on the behavior of a compiler faced with an instance of undefined behavior, the compiler (more importantly, any generated code) can do absolutely anything. In particular, there is no guarantee that at most the undefined bit of the program will behave badly, and that the rest of the program will perform normally. It's perilous to think that you can tolerate undefined behavior in a program, imagining that its undefinedness can't hurt; the undefined behavior can be more undefined than you think it can.
In summary:
Undefined behavior should be avoided whenever you possibly can.
It really can make demons fly out of your nose.
Or make the compiler silently eat entire branches of your code without telling you.
Or other distressing things.
In his article about undefined behavior, Regehr mentions that there are 191 different kinds of undefined behavior in the C99 spec. Its not reasonable to expect all programmers to know every single one of those, and I assume the situation with C++ is even worse. So I hope the standards committee makes a serious effort to trim down the undefined behavior in the future.
bob wrote:If you think about that for a minute, how can those be different? It would seem to me that "undefined" == "unspecified".
The answer to your question is in the C standard on page 3.
So, basically...
unspecified. Do whatever you want, just so you document it.
Almost. It is not a requirement to document unspecified behavior.
undefined. Do whatever you want, but don't document it.
Almost. It is not a requirement not to document undefined behavior.
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible". Apple should have read that.
I can't find where it says that. Not in the working draft that Ronald links to, and not in the approved standard itself. Can you give the reference?
I've tried to look again. I believe it was in something written on the topic. I'll try to search it down. But if you think about it, what would a "GOOD" compiler writer do besides "trying to do the right thing"??? IE would you expect him to just introduce random or bizarre behavior when the standard says "behavior is undefined"? Apple's breaking the strcpy() function is the exact opposite of what I, as a compiler writer, would do. I think like Linus. Rather then breaking memcpy() why not just redirect to memmove() which works perfectly for overlapping strings? Breaks nothing. Programs that did work continue to work.
I think that suggestion was actually from Torvalds. Somewhere along the way he queried something like "what is the purpose of software development? To make the work of others easier or harder?" The Glibc folks apparently thought the latter was perfectly acceptable.
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
No.
Unspecified behavior means there are a limited number of possibilities and the compiler is free to choose any one of them. A program that exhibits unspecified behavior must still have the semantics specified by the abstract machine in so far as it is specified. So your code should not depend for its correctness on a particular order in which function arguments are evaluated, because different C99-compliant compilers may evaluate them in a different order.
Undefined behavior means the standard does not impose any requirements whatsoever. Not on the program's compilation (the compiler may fail on it), not on the program's execution (it may delete all your data).
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
A compiler does not have to map C constructs to your hardware the way you expect it to do. If the compiler is able to detect that a branch of your code when executed leads to integer overflow, the compiler may decide to optimise that whole branch away..
Which is pure crap. It just might be that I understand integer overflow and its occurrence might not break my code at all. Hashing comes to mind but there are others as well.
I also like the mention of "undefined" means "anything can happen, but the compilers should do the 'right thing' whenever possible".
Where do you read this?
I think that was Torvald's statement, I am not sure.
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
No.
Unspecified behavior means there are a limited number of possibilities and the compiler is free to choose any one of them. A program that exhibits unspecified behavior must still have the semantics specified by the abstract machine in so far as it is specified. So your code should not depend for its correctness on a particular order in which function arguments are evaluated, because different C99-compliant compilers may evaluate them in a different order.
Undefined behavior means the standard does not impose any requirements whatsoever. Not on the program's compilation (the compiler may fail on it), not on the program's execution (it may delete all your data).
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
A compiler does not have to map C constructs to your hardware the way you expect it to do. If the compiler is able to detect that a branch of your code when executed leads to integer overflow, the compiler may decide to optimise that whole branch away..
Which is pure crap. It just might be that I understand integer overflow and its occurrence might not break my code at all. Hashing comes to mind but there are others as well.
You might consider it pure crap but the C standard explicitly lists integer overflow as an example of undefined behavior.
You thought you understood strcpy until Apple proved you wrong.
There is pedantic, and maliciously pedantic. Translating the use of an uninitialized variable into a call to a routine that formats the hard drive cannot be defended by arguing that 'undefined behavior' also covers formatting. That is just malicious, if not criminal. And optimizing away expressions that overflow comes perilously close.
unspecified. Do whatever you want, just so you document it.
undefined. Do whatever you want, but don't document it.
No.
Unspecified behavior means there are a limited number of possibilities and the compiler is free to choose any one of them. A program that exhibits unspecified behavior must still have the semantics specified by the abstract machine in so far as it is specified. So your code should not depend for its correctness on a particular order in which function arguments are evaluated, because different C99-compliant compilers may evaluate them in a different order.
Undefined behavior means the standard does not impose any requirements whatsoever. Not on the program's compilation (the compiler may fail on it), not on the program's execution (it may delete all your data).
I think some of their wording is nonsensical. Integer overflow is anything but undefined. At least my Intel hardware documentation tells me what to expect, exactly.
A compiler does not have to map C constructs to your hardware the way you expect it to do. If the compiler is able to detect that a branch of your code when executed leads to integer overflow, the compiler may decide to optimise that whole branch away..
Which is pure crap. It just might be that I understand integer overflow and its occurrence might not break my code at all. Hashing comes to mind but there are others as well.
You might consider it pure crap but the C standard explicitly lists integer overflow as an example of undefined behavior.
You thought you understood strcpy until Apple proved you wrong.
I didn't "think" I understood strcpy(). I DID understand strcpy(). I STILL understand strcpy(). take a look at the source. Apple made an arrogant and ill-conceived decision that has brought them a lot of flak from many different directions, just as the glibc guys did with memcpy().
Just because the standard says "undefined" doesn't mean there is "no result". If you understand integer overflow, then causing it is not ALWAYS a bug.
