Assert and undefined behavior

Ali Çehreli acehreli at yahoo.com
Wed Oct 11 18:25:35 UTC 2017


On 10/11/2017 02:27 AM, John Burton wrote:
 > The spec says this :-
 >
 > "As a contract, an assert represents a guarantee that the code must
 > uphold. Any failure of this expression represents a logic error in the
 > code that must be fixed in the source code. A program for which the
 > assert contract is false is, by definition, invalid, and therefore has
 > undefined behaviour."

The important part is that the "program" has undefined behavior 
according to *your* definition because you're the one who asserted that 
something should never have happened:

struct Square {
     int side;
     int area;

     invariant() {
         assert(area == side * side); // Could be inside foo()
     }

     void foo() {
     }
}

void main() {
     auto s = Square(1, 10);
     s.foo();
}

So, you think you wrote your program to never break that assertion. So, 
regardless of the reason for the failure (design error, memory 
corruption, hardware error, etc.), the program is outside of its 
well-defined state (by you).

 > I know this might seem like a small or pedantic point

Not only this specific point, but almost everything about assertion 
failures are very important and very interesting. For example, according 
to the text you quoted; the code injected by the compiler, the one that 
dumps a backtrace for an Error, should not be executed either. You have 
no guarantee that that code will really dump a backtrace, whether the 
output will be correct, etc. :/ (There has been many many long 
discussions about these topics on the D newsgroups.)

What gives me comfort is the fact that life is not perfect anyway.[1] 
Things somehow seem to work fine. :)

Ali

[1] Another example is mouse clicks (and screen taps). We have no 
guarantee that we are clicking what we wanted to. Sometimes a new window 
pops up and you click some random button but it works in general.



More information about the Digitalmars-d-learn mailing list