[PATCH 1/3] Document max_align_t

[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>)


> We could say that it's 8 on most 32-bit architectures, and 16 on 64-bit
> architectures.

The existing glibc manual says something along those lines (it's 
incorrect because it says it's 8 on all 32-bit architectures). I could 
resurrect that wording and correct it.


> Maybe drop the reference to signed size_t here?  I don't think we wan't
> people to write code deals with this situation anymore.

Makes sense, thanks.