C null pointer arithmetic

Question

I noticed this warning from Clang:

warning: performing pointer arithmetic on a null pointer
has undefined behavior [-Wnull-pointer-arithmetic]

In details, it is this code which triggers this warning:

uint8_t *end = ((uint8_t*)0) + sizeof(uint8_t) * count;

Why would arithmetic on a null pointer be forbidden when doing the same on a non-null pointer obtained from an integer different than zero does not trigger any warning ?

And more importantly, does the C standard explicitly forbid null pointer arithmetic ?

Answer 1

The C standard does not allow it.

6.5.6 Additive operators (emphasis mine)

8 When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

For the purposes of the above, a pointer to a single object is considered as pointing into an array of 1 element.

Now, ((uint8_t*)0) does not point at an element of an array object. Simply because a pointer holding a null pointer value does not point at any object. Which is said at:

6.3.2.3 Pointers

3 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 you can't do arithmetic on it. The warning is justified, because as the second highlighted sentence mentions, we are in the case of undefined behavior.

Don't be fooled by the fact the offsetof macro is possibly implemented like that. The standard library is not bound by the constraints placed on user programs. It can employ deeper knowledge. But doing this in our code is not well defined.

Answer 2

Little clarification on this thread.

First of all, this is undefined behavior per the C standard for the reasons cited by StoryTeller:

If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

Since the zero constant literal converted to any pointer type decays into the null pointer constant, which does not point to any contiguous area of memory, the behavior is undefined.

However, performing arithmetic operations on null pointers in order to retrieve offsets is not new, the C implementation of the offsetof macro uses it:

#define offsetof(st, m) ((size_t)&(((st *)0)->m))

And doing the same arithmetic fashion on pointers is also frequent:

int *end = (int *)0 + array_size;

This line is virtually the same as writing:

int *end = (int *)(sizeof(int) * array_size);

I believe the offset calculation is implementation defined, as the compiler “could” dereference such pointers in order to retrieve the actual memory offset, which is of course very improbable, but still possible.

Also, note that this warning for null pointer arithmetic is specific to Clang 6.0. GCC does not trigger it even with -fsanitize=undefined.