! vs == nil in objective-c [duplicate]

Question

If you have an object like NSString *someString, what is the difference, if any, between

if (!someString)

vs

if (someString == nil)

Thanks!

Answer 1

The first syntax you use:

 if (!someString)

exploits a sort of "ambiguity" of C deriving from the fact that the original standard of C lacked a proper boolean type. Therefore, any integer value equalling 0 was interpreted as "false", and any integer value different from "0" was taken as "true". The meaning of ! is therefore defined based on this convention and current versions of the C standard have kept the original definition for compatibility.

In your specific case, someString is a pointer, so it is first converted to an integer, then ! someString is interpreted as a bool value of true when someString points at the location 0x000000, otherwise it evals to "true".

This is fine in most conditions (I would say always), but in theory, NULL/nil could be different from 0x000000 under certain compilers, so (in very theory) it would be better to use the second syntax, which is more explicit:

 if (someString == nil)

It is anyway more readable and since someString is not an integer (rather a pointer), IMO, better practice in general.

EDIT: about the definition of NULL...

Whether the C standard defines NULL to be 0 is an interesting topic for me...

According to C99 standard, section 7.17, "Common definitions ":

NULL [which] expands to an implementation-defined null pointer constant;

So, NULL is defined in stddef.h to an implementation-defined null pointer constant... The same document on page 47 states:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

So, the null pointer constant (which is (void*)0) can be converted to a null pointer and this is guaranteed to compare unequal to a pointer to any object or function.

So, I think that basically it depends on whether the implementation decides that the result of converting a null pointer constant to a null pointer produces a pointer which converted back to an integer gives 0. It is not clear that a null pointer interpreted as an integer equals 0.

I would say that the standard really try and enforce the null pointer being 0, but leaves the door open to systems where the null pointer was not 0.

Answer 2

For most pointers, they're equivalent, though most coders I know prefer the former as it's more concise.

For weakly linked symbols, the former resolves the symbol (and will cause a crash if it's missing) while an explicit comparison against nil or NULL will not.