It seems unclear, but there are claims that dereferencing a nullpointer is undefined behavior:
This note was in fact removed as the result of DR 1102 with the stated reasoning being that it was not undefined behaviour to dereference a null pointer.
indicates that it might be defined behavior.
General agreement seems to be that it is undefined behavior.
So. Is it fine to call cv::setBreakOnError(true)
, which is supposed to cause raising an Access Violation on error()
? Its implementation is as follows:
if(breakOnError)
{
static volatile int* p = 0;
*p = 0;
}
Or does calling this function mean, that due to undefined behavior, anything could now happen when my program is compiled and run?
My own best guess is that it is technically undefined but happens to always(?) do the right thing on windows and linux
The reason dereferencing a null pointer value is said not to be undefined is they are using “dereferenced” to mean the *
operator is applied to the pointer, not that there is actually an attempt to access a pointed-to-object.
The DR 1102 you link to further links to issue 232, where we can see one of the examples given is typeid(*p)
. Evaluation of this when *p
is a polymorphic class type is defined to throw the exception bad_typeid
. That is a definition of behavior, so the behavior is not undefined.
Actually attempting to access the dereferenced pointer would be undefined; foo = *p
or *p = 0
would be undefined.