Difference between dereferencing NULL pointer and uninitialised pointer

Question

On code blocks(C++)

#include<bits/stdc++.h>
using namespace std;
int main(){
    int *p;
    cout<<*p;
}

produces garbage value, whereas

#include<bits/stdc++.h>
using namespace std;
int main(){
    int *p=NULL;
    cout<<*p;
}

results in runtime error. I expected runtime error for both (ideone produces runtime error for both) because both are bad pointers. How can one explain this?

Jeffries

#include<bits/stdc++.h> Whyyyyyyyy???????? Use standard headers!!!! – Mismanage

@GauravJain UB is UB, and will stay UB, so what do you expect other than demons flying out from your nostrils? – Delaware

Just how many dups are there of this stuff? – Galactometer

@MartinJames: How many students are there in insert place here? – Mismanage

Answer 1

Your expectation of a runtime error is flawed.

Dereferencing an uninitialised/invalid pointer with arbitrary value can do anything at all.

That means the potential symptoms range from:

• nothing happens
• something happens
• a runtime error happens
• your source code is spontaneously edited to use proper standard headers instead of misguidedly hacking in implementation "bits"
• your attitude in the comments section is magically improved
• your cat is murdered
• your cat is not murdered
• your cat is murdered and not murdered
• your cat murders itself
• a black hole opens inside your cat
• a cat opens up inside a black hole

and so on.

This is true for dereferencing NULL, too, but modern commodity hardware tends to treat NULL dereferences specially, usually guaranteeing a segmentation fault to aid in diagnostics. Obviously, a CPU cannot do that for arbitrary pointer values, because they may be valid as far as it knows!

Mismanage

/me tries to picture a cat opening up inside a black hole and fails miserably :) – Incivility

@T.C.: Probably summat like this: thefinchandpea.files.wordpress.com/2014/08/… – Mismanage

Answer 2

Your first example,

int *p;
cout << *p;

is taking a wild pointer and attempting to dereference it. What's at the other end of that pointer? Is it a system location that will cause a run time error? Is it the address of x, another variable in your program? Is it a piece of memory your web browser is using? Attempting to dereference and read or write to this location is undefined behavior, there's no guarantee of what will happen (time travel has been reported in extreme instances).

Dereferencing a null pointer (a pointer to the 0 address) however, is also undefined, but will likely result in a segmentation fault--a run time error.

Wasting

Answer 3

In the first code as we are not setting the pointer it is taking random value address... Which may have some garbage value. But in second case pointer is not pointing to any address so obviously it will fail

Cark