When does invoking a member function through a null pointer result in undefined behavior?

Question

Consider the following code:

#include <iostream>

struct foo
{
    // (a):
    void bar() { std::cout << "gman was here" << std::endl; }

    // (b):
    void baz() { x = 5; }

    int x;
};

int main()
{
    foo* f = 0;

    f->bar(); // (a)
    f->baz(); // (b)
}

We expect (b) to crash, because there is no corresponding member x for the null pointer. In practice, (a) doesn't crash because the this pointer is never used.

Because (b) dereferences the this pointer ((*this).x = 5;), and this is null, the program enters undefined behavior, as dereferencing null is always said to be undefined behavior.

Does (a) result in undefined behavior? What about if both functions (and x) are static?

Answer 1

Treating all call made using method syntax as invoking Undefined Behavior when the target is null allows a compiler given something like:

void test()
{
  if (this) doSomething(this); else handleNullCase();
}

to replace that code with an unconditional call to doSomething(this);. Some compilers whose customers happen to like that behavior work that way, and the authors of the Standard don't want to mandate that such compilers behave in a manner their customers wouldn't like as much.

Note that the Standard also allows compilers whose customers would prefer to have somePtr->nonVirtualMember pass nonVirtualMember the value of somePtr in a manner agnostic to whether somePtr is null, and have the called function process the check of this likewise, to do those things.

When the C and C++ Standard were written, the authors often wanted to write the standards in whatever way they thought would best allow compiler writers to satisfy the desires of a variety of customers.

Answer 2

With CWG 2823 for C++26, and as defect report, it has now been clarified that dereferencing a null pointer has in itself undefined behavior even if no lvalue-to-rvalue conversion is applied on the result or the result is used in any other way, i.e. "empty lvalues" don't exist.

[expr.unary.op]/1 now says about the behavior of the built-in unary * operator:

[...] If the operand points to an object or function, the result denotes that object or function; otherwise, the behavior is undefined except as specified in [expr.typeid].

With CWG 2748 for C++26, and as defect report, it has also been clarified that the pointer dereference in a member access expression is evaluated even if the member is static and the result of the dereference isn't actually needed.

[expr.ref]/3 now states

The postfix expression before the dot is evaluated; [...]

after transformation of E1->E2 to ((*E1)).E2 per [expr.ref]/2:

[...] The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of [expr.ref] will address only the first option (dot).

A note in [expr.ref] further clarifies:

If the class member access expression is evaluated, the subexpression evaluation happens even if the result is unnecessary to determine the value of the entire postfix expression, for example if the id-expression denotes a static member.

Therefore there is now no ambiguity anymore that a member function call, whether static or non-static, has undefined behavior on a null pointer value.

MSVC currently mistakenly does not consider a call to a non-static member function on a null pointer value UB, while both GCC and Clang correctly do. See https://godbolt.org/z/zeGPzacEE.

For static member functions, currently all three compilers fail to identify the static member function call on a null pointer value as UB, see https://godbolt.org/z/G1bPYPqEP. Generally they do not consider the null pointer dereference itself as UB currently, see https://godbolt.org/z/T7Yo1E1Yh. Presumably the defect reports haven't been implemented yet.

Answer 3

Obviously undefined means it's not defined, but sometimes it can be predictable. The information I'm about to provide should never be relied on for working code since it certainly isn't guaranteed, but it might come in useful when debugging.

You might think that calling a function on an object pointer will dereference the pointer and cause UB. In practice if the function isn't virtual, the compiler will have converted it to a plain function call passing the pointer as the first parameter this, bypassing the dereference and creating a time bomb for the called member function. If the member function doesn't reference any member variables or virtual functions, it might actually succeed without error. Remember that succeeding falls within the universe of "undefined"!

Microsoft's MFC function GetSafeHwnd actually relies on this behavior. I don't know what they were smoking.

If you're calling a virtual function, the pointer must be dereferenced to get to the vtable, and for sure you're going to get UB (probably a crash but remember that there are no guarantees).

Answer 4

Both (a) and (b) result in undefined behavior. It's always undefined behavior to call a member function through a null pointer. If the function is static, it's technically undefined as well, but there's some dispute.

---

The first thing to understand is why it's undefined behavior to dereference a null pointer. In C++03, there's actually a bit of ambiguity here.

Although "dereferencing a null pointer results in undefined behavior" is mentioned in notes in both §1.9/4 and §8.3.2/4, it's never explicitly stated. (Notes are non-normative.)

However, one can try to deduced it from §3.10/2:

An lvalue refers to an object or function.

When dereferencing, the result is an lvalue. A null pointer does not refer to an object, therefore when we use the lvalue we have undefined behavior. The problem is that the previous sentence is never stated, so what does it mean to "use" the lvalue? Just even generate it at all, or to use it in the more formal sense of perform lvalue-to-rvalue conversion?

Regardless, it definitely cannot be converted to an rvalue (§4.1/1):

If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.

Here it's definitely undefined behavior.

The ambiguity comes from whether or not it's undefined behavior to deference but not use the value from an invalid pointer (that is, get an lvalue but not convert it to an rvalue). If not, then int *i = 0; *i; &(*i); is well-defined. This is an active issue.

So we have a strict "dereference a null pointer, get undefined behavior" view and a weak "use a dereferenced null pointer, get undefined behavior" view.

Now we consider the question.

---

Yes, (a) results in undefined behavior. In fact, if this is null then regardless of the contents of the function the result is undefined.

This follows from §5.2.5/3:

If E1 has the type “pointer to class X,” then the expression E1->E2 is converted to the equivalent form (*(E1)).E2;

*(E1) will result in undefined behavior with a strict interpretation, and .E2 converts it to an rvalue, making it undefined behavior for the weak interpretation.

It also follows that it's undefined behavior directly from (§9.3.1/1):

If a nonstatic member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

---

With static functions, the strict versus weak interpretation makes the difference. Strictly speaking, it is undefined:

A static member may be referred to using the class member access syntax, in which case the object-expression is evaluated.

That is, it's evaluated just as if it were non-static and we once again dereference a null pointer with (*(E1)).E2.

However, because E1 is not used in a static member-function call, if we use the weak interpretation the call is well-defined. *(E1) results in an lvalue, the static function is resolved, *(E1) is discarded, and the function is called. There is no lvalue-to-rvalue conversion, so there's no undefined behavior.

In C++0x, as of n3126, the ambiguity remains. For now, be safe: use the strict interpretation.