There is a well known pattern of figuring out array length:
int arr[10];
size_t len = sizeof(arr) / sizeof(arr[0]);
assert(len == 10);
This pattern applies to static arrays and auto arrays of constant size. It also applies to variable length arrays in C99.
I want to apply similar idea for figuring out dynamic array size in bytes:
size_t known_len = 10;
int *ptr = malloc(known_len * sizeof(int));
size_t size = known_len * sizeof(ptr[0]);
assert(size == known_len * sizeof(int));
This is nicer than known_len * sizeof(int) because sizeof(ptr[0]) doesn't refer to actual array element type. Hence it doesn't require reader of the code to know the type.
However it is unclear to me whether expression sizeof(ptr[0]) can lead to undefined behavior. As it is expanded:
sizeof(ptr[0]) -> sizeof(*((ptr) + (0))) -> sizeof(*ptr)
The result expression is questionable in case if ptr is 0:
sizeof(*((int*) 0))
According to a C99 standard:
(C99, 6.3.2.3p3 ): "An integer constant expression with the value
0, or such an expression cast to typevoid *, is called a null pointer constant." Dereferencing a null pointer is undefined behavior.(C99, 6.5.3.2.p4) "If an invalid value has been assigned to the pointer, the behavior of the unary
*operator is undefined.87)"87): "Among the invalid values for dereferencing a pointer by the unary
*operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime."
But it's never specified whether sizeof of such expression can lead to undefined behavior. In fact such sizeof should be evaluated at compile time.
My questions are:
sizeof(ptr[0]) be used in the code when type of ptr is known and the value of ptr is not known? The expression ptr[0] will not be evaluated in sizeof(ptr[0]). Size will be determined by just using the type of ptr[0] at compile time.
The
sizeofoperator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer. If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is aninteger constant.
That means, there is no undefined behavior.
This will not cause undefined behavior.
With the exception of taking the size of variable-length arrays, sizeof is a compile-time constant expression. The compiler processes the expression to determine its type, without producing the code to evaluate the expression at compile time. Therefore, the value at ptr[0] (which is an uninitialized pointer) does not matter at all.
Moreover, if you would like to allocate ten integers, you should be calling malloc like this:
int *ptr = malloc(known_len * sizeof(ptr[0]));
Otherwise, you allocate ten bytes, which is too small for storing ten integers. Note that in the expression above ptr is uninitialized at the time of the call, which is perfectly fine for sizeof.
In general case, if I'm missing something, dereferencing a null pointer under sizeof can lead to undefined behavior. Since C99, sizeof is not a purely compile time construct. The operand of sizeof is evaluated at run-time if the operand type is a VLA.
Consider the following example
unsigned n = 10;
int (*a)[n] = NULL; // `a` is a pointer to a VLA
unsigned i = 0;
sizeof a[i++]; // applying `sizeof` to a VLA
According to the C99 standard, the argument of sizeof is supposed to be evaluated (i.e. i is supposed to get incremented). Yet I'm not entirely sure that the null-point dereference in a[0] is supposed to produce undefined behavior here.