Markus Geimer <[email protected]> writes:

Well, according to the C99 standard "Each non-bit-field member of a structure or union object is aligned in an *implementation-defined* manner appropriate to its type." (§6.7.2.1) It is therefore not guaranteed that the two ints in the struct are contiguous -- which means that, strictly speaking, int[2] is the only portable choice. (Although I'm not aware of any compiler that would insert padding between the two ints, i.e., in practice the struct should be fine, too.)

C11 adds the _Alignof operator and elaborates further on alignment. Although the wording is ambiguous in the section on structs, I think the intent is clear that the "implementation-defined" alignment is indeed the implementation-defined value returned by _Alignof and discussed in C11 §6.2.8 Alignment of objects: Complete object types have alignment requirements which place restrictions on the addresses at which objects of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type: stricter alignment can be requested using the _Alignas keyword. _Alignof cannot reasonable return a value larger than sizeof, for that would break idioms such as (§6.5.3.4.7) sizeof array / sizeof array[0] Anyway, alignment rules apply everywhere, not just in structs, so there can be no difference in layout between typedef int array_2int[2]; and typedef struct {int value,loc;} struct_2int; The reiteration of "implementation-defined" in the section on structs is likely because that is a place where alignment semantics are directly observable (versus allocation of automatic/stack variables).