Take the 2-minute tour ×

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_;
share|improve this question
demons will fly out of your nose –  jk. Feb 19 '13 at 11:22
text book undefined behavior, in other words it might segfault, it might work nicely or it might format your hardrive –  ratchet freak Feb 19 '13 at 11:25
@ratchetfreak - if you expanded upon that comment, that would have made for a very good answer. –  GlenH7 Feb 19 '13 at 14:55

2 Answers 2

up vote 22 down vote accepted

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.)

share|improve this answer
You certainly could specify that in the standard. For example, .Net does that. The problem is, it means each variable has to be automatically nulled out, which causes performance penalty. And on platforms without memory protection, it would mean automatic null check before each pointer dereference, which is even worse. –  svick Feb 19 '13 at 15:39

The machine and OS I first did some C++ programming on didn't even have seg faults because it didn't have any memory protection.

If I recall correctly, on that platform, your code snippet would have ClassType_ptr being 0 initially, and dereferencing it would (without error) return the first four bytes of RAM as an integer. Not what you wanted, surely, but no crash, no error.

That's why, as Kilian Foth said in the above answer, the behaviour is undefined.

share|improve this answer
If the Classtype_ptr declaration is at the top-level then it will be initialized to a null pointer. If it is deeper down then there could be any value in it, including one that happens to be a valid pointer. –  NovaDenizen Feb 19 '13 at 13:03
This was C, and not C++, but if I recall correctly, address 0 on the original DOS contained a pointer to the divide by zero interrupt handler. This meant that you could store and retrieve data from it without causing a crash until quite a while later. –  Steven Burnap Feb 19 '13 at 20:45
This was an Amiga, not a DOS machine, but yeah RAM from 0x000000 to 0x0000ff was interrupt vectors. I think you'd break something horribly writing to a zero pointer, but certainly not reading from it. –  Carson63000 Feb 20 '13 at 10:21
MacOS had the same thing where you could read from 0x000000 without problems, though writing would usually crash the computer. I think that 68k architecture allows a read from address 0. –  Michael Shopsin Feb 22 '13 at 20:10

Your Answer


