3

Does the following snippet compile/execute the block in the if-statement?

int* pointer = NULL;
int deref = *pointer;
if(deref == NULL){
  // will execute?
}

Since the pointer variable contains NULL does the dereference of this pointer variable also return NULL or will this result in a runtime error?

xetra11
  • 7,671
  • 14
  • 84
  • 159
  • 1
    in cannot be dereferenced – phuclv Sep 21 '16 at 05:36
  • 1
    @LưuVĩnhPhúc The ISO C standard doesn't impose any requirements like "cannot happen" to the dereferencing of a null pointer. It is undefined behavior, and in fact can be done in some environments and can be provided as a documented language extension (though not a very well considered one, obviously). – Kaz Sep 21 '16 at 05:39
  • Historically, it has happened that C programmers exploited dereference-able null pointers to simplify the cases in linked list or tree data structures. you can do things like `head_node->next->prev = that` without worrying that `nead_node->next` is the terminating null link. Obviously, that code was found not to be portable to environments that trap null references, oops! It wasn't wrong; it worked fine on the original target platforms, and code was shipped to happy end users. It was **nonportable**. – Kaz Sep 21 '16 at 05:43
  • @Kaz C is not a mentioned tag - just C++. – Johann Gerell Sep 21 '16 at 08:06
  • @LưuVĩnhPhúc "cannot" isn't entirely correct. It _can_ be done, but the result is undefined. – Johann Gerell Sep 21 '16 at 08:08
  • Anything could happen because your program exhibits undefined behaviour. By the way: if you are using C++11 prefer nullptr. – user3721426 Sep 21 '16 at 08:08

3 Answers3

3

The result is "undefined behaviour", which may or may not trigger a runtime error, and should in any case always be avoided.

Brian Bi
  • 111,498
  • 10
  • 176
  • 312
2

Once you set: 

int* pointer = NULL;

pointer points to nothing. Now when you write this: 

int deref = *pointer;

deref will try to access what pointer points to, which will lead to an undefined behaviour like segmentation fault.

I hope this explains.

adisticated
  • 469
  • 2
  • 10
1

The current answers addressed the UB very well. However, I want to add something. If you run this code:

if(0==NULL){
    std::cout << "True";
}

It will prints True. So if dereferencing a null pointer on your specific environment leads to returning 0 (which is not a steady case. It is UB), the part inside your if statement will execute.

I just wanted to clarify why it is working on some machines. However, that does not change anything about the fact that it is UB.

Humam Helfawi
  • 19,566
  • 15
  • 85
  • 160
  • Just pointing out that your example doesn't _dereference_ `NULL`, but the following paragraph _does_ talk about that. What was your intent? – Johann Gerell Sep 21 '16 at 08:14
  • @JohannGerell I just wanted to inform the OP that his code might work on some machines and execute the instructions inside the if-statement. This behaviour still undefined but some coders may think that it is defined since it is working and behave like theirs intention. So, I see it worth to tell. – Humam Helfawi Sep 21 '16 at 08:30
  • What you're addressing then is the case when the '0' in your example `if(0==NULL)` happens to be the result of dereferencing a null pointer on some platform some time, right? I was confused by how you formulated this. – Johann Gerell Sep 21 '16 at 09:10
  • Yup exactly that what I meant – Humam Helfawi Sep 21 '16 at 09:18