Does idiomatic initialization of a dynamic array invoke Undefined Behavior?

Question

This question may be a bit controversial. I have a following code at block scope:

int *a = malloc(3 * sizeof(int));
if (!a) { ... error handling ... }
a[0] = 0;
a[1] = 1;
a[2] = 2;

I argue that this code invokes UB due to pointer arithmetics outside of bounds. The reason is that the effective type of the object pointer by a is never set to int[3] but rather int only. Therefore any access to the object at an index other than 0 is not defined by C standard.

Here is why:

Line a = malloc(...). If the allocation succeeds thena points for a region large enough to store 3 ints.

a[0] = ... is equivalent to *a = ..., an l-value of int. It sets the effective type of the first sizeof(int) bytes to int as indicated in the rule 6.5p6.

... For all other accesses to an object having no declared type, the effective type of the object is simply the type of the lvalue used for the access.

Now the pointer a points to an object of type int, not int[3].

a[1] = ... is equivalent to *(a + 1) =. Expression a + 1 points to an element one after the end of int object accessible through *a. This pointer itself is valid for comparison but accessing is undefined due to:

Rule 6.5.6p7:

... a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type.

And rule 6.5.6p8:

... 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.

The similar issue is relevant for a[2] = ... but here even a + 2 hidden in a[2] invokes UB.

The issue could be resolved if the standard allowed arbitrary pointer arithmetic with the valid region of memory as long as alignment requirements and strict aliasing rule is satisfied. Or that any collection of the consecutive objects of the same type can be treated as an array. However, I was not able to find such a thing.

If my interpretation of the standard is correct then some C code (all of it?) would be undefined. Therefore it is one of those rare cases when I hope that I am wrong.

Am I?

Answer 1

The Standard only "halfway" defines the term "object": it says that every object is a region of storage, but it does not specify when a region of storage is or is not an object. For most of the Standard, it would be fine to say that every region of storage simultaneously contains all objects of all types that will fit therein; any action which modifies an object modifies the underlying storage, and any action which modifies the underlying storage modifies the stored value of all objects therein.

I think it's fairly clear that the authors of the Standard expected that in cases where the Standard says an action invokes Undefined Behavior, but the behavior would be defined in the absence of that statement, quality implementations should behave in the defined fashion in cases where their customers would find that useful. The question of which cases those are, however, is a Quality of Implementation issue outside the Standard's jurisdiction. As such, it didn't really matter if the Standard characterized as Undefined Behavior some action which all implementations to date had processed in the same obviously-useful fashion, because nobody seeking to sell compilers would interpret the Standard's failure to mandate such a behavior as an invitation to deviate from it in ways that would be detrimental to their customers.

Because different compilers are used for different purposes, the only way the Standard could actually define all the behaviors which would be needed for many low-level programming tasks while also allowing all of the optimizations that would be useful for high-end number crunching would be to either recognize categories of implementations that make different optimizations, or add better means of inviting or blocking optimizations that would usefully improve performance and/or result in incorrect program behavior. Because every compiler that has ever existed or will plausibly ever exist will refrain from making some optimizations that would otherwise have been useful, and/or perform "optimizations" which incorrectly process some Strictly Conforming C11 programs, the question of whether the Standard would allow a silly optimization should only be relevant to people who either want to write poor quality compilers, or who want to bend over backward to be compatible with them.