[PATCH 1/3] Document max_align_t
Florian Weimer
fweimer@redhat.com
Tue Feb 10 12:38:57 GMT 2026
* Paul Eggert:
> On 2026-02-06 01:24, Florian Weimer wrote:
>> * Paul Eggert:
>>> +Code can use @code{alignof (max_align_t)} when calculating space
>>> +needed for arbitrary collections of objects, so long as the objects'
>>> +types are fundamental and lack stricter alignment specifiers.
>>> +@end deftp
>> I think this is not entirely accurate because for ABI compatibility
>> reasons, we do not increase max_align_t when we add new types.
>
> I don't see a contradiction; any such new types need not have
> fundamental alignment. The only types required to have fundamental
> alignment are those so specified by the C standard.
>
> I could list all those types more explicitly (instead of merely
> indicating them), and say that other types need not have fundamental
> alignment. It's a long list, though. Here it is:
>
> char
> all integer types (including bool)
> float, double, long double
> _Decimal32, _Decimal64, _Decimal128
> float _Complex, double _Complex, long double _Complex
> all enumerated types
> all pointer types
> all array types whose element types have fundamental alignment
> all struct and union types whose element types all have
> fundamental alignment, and which lack stricter
> alignment specifiers
> va_list (in <stdarg.h>)
> fpos_t (in <stdio.h>)
> cnd_t, thrd_t, tss_t, mtx_t, once_flag (in <threads.h>)
> mbstate_t (in <wchar.h>)
What about POSIX-defined types where object definitions are permitted,
such as pthread_mutex_t?
I think authors of replacement mallocs need to know these rules.
Thanks,
Florian
More information about the Libc-alpha
mailing list