The very simple piece of C++ code below is incorrect, it\'s easy to see why and
ID: 654273 • Letter: T
Question
The very simple piece of C++ code below is incorrect, it's easy to see why and tools like Valgrind will tell you. In running several C++ codes containing this kind of error, I noticed that each time, it ended up with a Segmentation fault at the line which tries to use the address.
So my question is: is it safe to claim that trying to use an address before it's allocated will inevitably lead to a Segmentation violation at the corresponding line?
class ClassType
{
public:int data_;
};
....
// Using address before it's allocated
ClassType * ClassType_ptr;
int x = ClassType_ptr->data_;
Explanation / Answer
No, absolutely not. If that were what invariably happens, we could use that to our advantage and specify it in the standard; known behaviour, even if it is a crash, is virtually always better than unknown behaviour.
But instead, the system response depends on details of the implementation, of the previous actions of the program, on the state of the runtime etc. in an unpredictable way. On modern operating systems referencing an address that doesn't belong to you may usually trigger a segmentation violation, but definitely not always. A segmentation violation might occur, but not until much later. Even worse, your program might appear to work but silently do the wrong thing. That's why the language standard has to take the worst possible option and declare that the behaviour is undefined.
(Note that goodness depends on your viewpoint. For the compiler implementor, undefined behaviour is good because it means that whatever you do is, by definition, right. For the application programmer it is bad, because it leads to application errors, and even to the particularly insidious kind of errors where things sometimes work and then fail spectacularly at the least opportune moment.)
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.