Is passing pointer to an array as pointer to pointer UB in C?

I have such a code:

#include <stdlib.h>
#include <stdio.h>

void func(int **b)
{
	printf("b = %p\n", b); // 0x7ffe76932330
	*b = *b + 1;
}

int main(void)
{
	int b[10] = {0};

	printf("b = %p\n", &b[0]); // 0x7ffe76932330
	printf("%d\n", b[0]);      // 0

	func(&b);

	printf("%d\n", b[0]); // 4
	return 0;
}

Does this code have UB? To me it seems so, at least due to different types without explicit casting int (*)[10] != int **.

Also, what if I have char b[] = "some string"; instead? The behavior is almost the same... weird.

Passing the pointer by itself isn't necessarily undefined behavior, but subsequently using the converted pointer is.

C allows conversions from one object type to another and back, as documented in section 6.2.3.2p7 of the C standard:

> A pointer to an object type may be converted to a pointer to a
> different object type. If the resulting pointer is not correctly
> aligned for the referenced type, the behavior is undefined.
> Otherwise, when converted back again, the result shall compare equal
> to the original pointer. When a pointer to an object is converted to a
> pointer to a character type, the result points to the lowest addressed
> byte of the object. Successive increments of the result, up to the
> size of the object, yield pointers to the remaining bytes of the
> object.

So assuming there's no alignment issue (i.e. the array starts on an 8 byte offset on a 64 bit system), just the action of passing a int (*)[10] to a function expecting an int ** is allowed, although most compilers will warn about converting incompatible pointer types.

The undefined behavior happens here:

*b = *b + 1;

Because you're derferencing an object though an incompatible pointer type (other than a char *). The rules regarding what you're allowed to dereferences are listed in section 6.5p7:

> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:
> - a type compatible with the effective type of the object,
> - a qualified version of a type compatible with the effective type of the object,
> - a type that is the signed or unsigned type corresponding to the effective type of the object,
> - a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
> - an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a
> subaggregate or contained union), or
> - a character type.

Dereferencing a int (*)[10] as a int ** doesn't meet any of the above criteria, so *b is undefined behavior.

An array is not a pointer, thus a pointer to an array as you pass to func with func(&b) is not a pointer to a pointer. It is a pointer to an array, an unusual type that is produced when passing an array of arrays to a function (int b[10][10] defines an array of arrays of int).

Passing &b to func involves a conversion between pointer types, Something the C Standard allows, but programmers should be careful about: the compiler would issue a warning if configured properly: -Wall -Werror is recommended for gcc and clang.

Regarding the undefined behavior itself: you pass &b to func expecting an int **. The compiler performs a conversion from the type of &b, which is int(*)[10] to the type int ** which might have a different alignment requirement. Indeed b is aligned on the width of int (usually 4 bytes), whereas int * may require an alignment of 8 bytes, as is the case on most 64-bit systems.

The C23 standard specifies this conversion as having undefined behavior:

> 6.3.2.3 Pointers:
>
> A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.

So the Standard describes the very conversion as having undefined behavior.

If int * and int have the same alignment requirements, which is the case for example on 32-bit systems, you don't get undefined behavior when passing &b to func, but you do when evaluating the expression *b = *b + 1; because:

> 6.5 Expressions
>
> An object shall have its stored value accessed only by an lvalue expression that has one of the following types:<br>
> - a type compatible with the effective type of the object,
> - a qualified version of a type compatible with the effective type of the object,
> - a type that is the signed or unsigned type corresponding to the effective type of the object,
> - a type that is the signed or unsigned type corresponding to a qualified version of the effective
type of the object,
> - an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
> - a character type.

Hence dereferencing b in *b = *b + 1 has undefined behavior. For illustration, you can try calling func(&(b+1)) to check if the undefined behavior is more visible (the program might exit with a bus error).

Also note that printf expects a void * for %p, so b and &b[0] must be cast as (void *) to avoid 2 more instances of undefined behavior.

The type of the expression &b is int ( * )[10]. There is no implicit conversion from a pointer of the type int ( * )[10] to a pointer of the type int **. So the compiler should issue a message for this statement

func(&b);

But even if you will cast the argument expression like:

func( (int ** )&b);

Nevertheless dereferencing the obtained pointer expression can invoke undefined behavior. That is the expression &b used in the function call has the same address value as the address value of the first element of the array.

So within the function the expression *b yields the value of the first element (if sizeof( int * ) is equal to sizeof( int ) when for example the both are equal to 4) of the passed array or a combined value of two first elements of the passed array (if sizeof( int * ) is equal to 2 * sizeof( int ) when for example the size of pointer is equal to 8 and the size of integer equal to 4).

That is the expression *b will not contain a valid address.

Thus this statement:

*b = *b + 1;

does not make sense. In the provided example as the initial array is zero initialized the expression *b can produce a null pointer. You could test the expression within the function for example the following way

printf( "*b == NULL is %s\n", *b == NULL ? "true" : "false" );

The same problem will take place with the character array:

char b[] = "some string";

if you will use it the same way.

Instead you could write for example:

int b[10] = {0};

int *pb = b;

func( &pb );

In this case the expression *b within the function will point to the first element of the passed array and this statement:

*b = *b + 1;

will increment the obtained pointer that will now point to the second element of the array.