[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