Issue 1104: Flexible array members and alignment

Authors: Jay Ghiron
Date: 2026-09-03
Submitted against: C23
Status: Open
Cross-references: 1090

Consider the following program:

#include<stddef.h>
#include<stdlib.h>
struct S{int x;short y;char z[];};
int main(){
struct S*p=malloc(offsetof(struct S,z)+1);
/* ... */
free(p);
}

Before C23 this was surely valid, but with N2293 it appears that if all of the following are true then it would be possible for it to be invalid:

If all of these are true, then it would not be guaranteed that the pointer resulting from malloc will be aligned sufficiently for struct S*. See also issue 1090 which discusses an example similar to this. If this should be a valid way to allocate space sufficient for an object of type struct S whose z member is an array of one, then it should be sufficient to obtain the proper alignment too. A second case where this issue with alignment can arise without the structure having an unnecessary greater alignment requirement is:

#include<stddef.h>
#include<stdlib.h>
struct U{char a;int b[];};
int main(){
struct U*q=malloc(offsetof(struct U,b));/* array of zero */
/* ... */
free(q);
}

Before C23 this was surely valid, but with N2293 it appears that if all of the following are true then it would be possible for it to be invalid:

If all of these are true, then it would not be guaranteed that the pointer resulting from malloc will be aligned sufficiently for struct U*. If this should be a valid way to allocate space sufficient for an object of type struct U whose b member is an array of zero, then it should be sufficient to obtain the proper alignment too. Another issue with alignment and flexible array members is:

As a special case, the last member of a structure with more than one named member can have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply. However, when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, it behaves as if it had one element but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past it.

(C23 6.7.3.2 "Structure and union specifiers" paragraph 20.)

It is mentioned that the size of a structure may be different due to a flexible array member, but it is never stated that the alignment requirements may be different. No implementations avoid changing the alignment requirements when flexible array members are used, since it would imply that every structure needs to have the maximum possible alignment requirement.

The following three points should fix these issues, and it seems unlikely that implementations would have trouble implementing them:

  1. For any valid fundamental alignment N, malloc(M) is guaranteed to return a pointer sufficiently aligned for N if M is greater than or equal to N (null is considered sufficiently aligned for any alignment). This would impose no further requirements on implementations where for each such N there exists a complete object type T such that alignof(T)==N&&sizeof(T)==N.
  2. The alignment requirements of structures and unions are defined exactly as: the maximum of the alignment requirements of the types specified in the members and the alignments of any alignment specifiers which apply to the members.
  3. Update 6.7.3.2 paragraph 20 to mention that the alignment may be different with flexible array members.

Alternatively, if the second point is not possible then strengthening the requirements of malloc further should also work. That is, malloc(offsetof(T,m)) is guaranteed to be sufficiently aligned for any complete structure type or complete union type T where m names a flexible array member in T.

Atomic structure types and atomic union types are intentionally not discussed, since it is not possible to access the flexible array members in them.