Crash behavior on null reference

Question

When bad C++ code tries to create a null reference like the following:

int &ptr2ref(int *p){
    return *p;
}

int calc(int &v){
    return v*2;
}

...
int &i = ptr2ref(nullptr);
calc(i);

At least in Visual C++ it crashed in the return statement of function calc (debug mode).

However, the answer of this question quotes

8.3.2/1:

A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. ]

1.9/4:

Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer)

If I understand right, the standard said that as soon as a null reference being created the program behavior is being undefined. So if a compiler intended to generate useful debug information it should crash at function ptr2ref in the above example, since there is where the null reference being created (and the deferencing happening).

Am I missed something? Are there any issue stops the compiler generate such code in at lest debug mode?

Undefined Behaviour

I know people will argue that "undefined" means roughly everything. My argument is, given the fact that the standard did not specify how long a simple int main(){} shall take to compile, no one will accept a compile time to be more than a day. So the problem is about implementation options, not the standard itself. I quoted the standard here is just to say that crash on ptr2ref IS an option.

Furthermore, there is already a lot of additional checking happening in debug mode, for example, the stack was always checked to see if there are any corruption before returning from the function. Compare to those I don't think add a relatively simple check will be too expansive in debug mode.

Answer 1

"Undefined behavior" does not mean "Crash Now".

It is defined in the C++ standard, section 1.3.24

Behavior for which this International Standard imposes no requirements

[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.

• The program is not required to crash as soon as you bind your null reference.
• Having a compiler generate code to check those cases would incur a dramatic overhead on the program, which is not acceptable.

Answer 2

"Undefined behavior" means that anything can happen and the compiler is not obligated to do anything specific. In this case here, nothing catastrophic happens on the null pointer dereference, it just brings the program in an invalid state by creating a null reference. Which causes problems later on.

Of course it would be desirable if the error could be detected earlier, but the only way to do so would be for the compiler to add explicit null pointer checks to all dereference operations, which would only waste performance in a well behaved (no null pointers used incorrectly) program. Since null pointer dereferences usually quickly lead to crashes anyway, this is probably not seen as being worth it even in debug mode.

Answer 3

If I understand right, the standard said that as soon as a null reference being created the program behavior is being undefined.

Yes that is correct. The text that assures this is:

A reference shall be initialized to refer to a valid object or function.

The result of dereferencing a null pointer is certainly not a valid object or function.

You also quote the following text:

[Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. ]

However, "Note" means that it is non-normative, i.e. the text is meant to be explanatory but does not actually constitute a part of the standard specification. And, somewhat surprisingly, it turns out that the Standard doesn't actually say anywhere (that I'm aware of) that *p causes undefined behaviour.

It does say that lvalue-to-prvalue conversion on *p causes undefined behaviour, but it also says that this conversion is not performed in the case of binding a reference.

This came up in issue 1102 .