Is it safe to check if a pointer is null, then dereference it in the same if statement?

Question

Is the following code safe if a null pointer is passed in?

if(ptr && *ptr == value)
{
   //do something
}

Does the order of the checks

Answer 1

Yes (1) is safe because of short circuiting. This is the way that the logical statement is evaluated. If the first part of the && statement is false then the whole statement can never be true so it will not try to evaluate the second part.

and (2) is unsafe because it dereferences the null pointer first, which is undefined behaviour.

edit:

in reference to KerrekSBs comment below: Why dereferencing a null pointer is undefined behaviour?

From the first answer in that post:

Defining consistent behavior for dereferencing a NULL pointer would require the compiler to check for NULL pointers before each dereference on most CPU architectures. This is an unacceptable burdern for a language that is designed for speed.

Also there is (was historically) hardware where the memory pointed to by NULL (not always 0) is in fact addressable within the program and can be dereferenced. So because of a lack of consensus and consistency it was decided that dereferencing a null pointer would be "undefined behaviour"

Answer 2

If the pointer is invalid (or rather NULL as pointed out), in the first version short-circuiting will prevent the evaluation of *ptr == value, so the first one is safe.

The second one will always access *ptr, whether it is valid or not.

Answer 3

The former is correct and safe, the latter is not.

The built-in && operator has short-circuit semantics, meaning that the second argument is evaluated if and only if the first one is true.

(This is not the case for overloaded operators.)

Answer 4

In addition to all the others answers about ptr && *ptr == value being valid, but not the other way round, the notion of valid pointer may have different meaning.

The ptr could be an uninitialized variable, or could be obtained (e.g. by a cast from some random intptr_t integer) in such a way that it does not point anywhere (e.g. a dangling pointer) but is not null.

In that case, neither order of testing works.

Some pointers can be invalid and be non-null (then testing ptr && *ptr == value is undefined behavior). There is no portable way to test them. (but you could use operating-system or processor specific tricks).