Re: alignas (C11)

On Thu, Nov 13, 2025 at 12:39 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> - You cannot use alignas on a typedef.  So some uses of the attribute
> pg_attribute_aligned() like for PgAioUringContext or the whole int128
> business cannot be converted directly.  The solution for cases like
> PgAioUringContext could be to move the alignas into the struct, but I
> haven't studied this code closely enough, so I'm leaving it.

While studying atomics recently I noticed BUFFERALIGN, which was
originally something like PG_IO_ALIGN_SIZE (see pg_config_manual.h),
but is now used as an arbitrary fudge-factor by shared memory
allocator-ish things that either know the memory will hold
pg_atomic_uint64 or don't know what the memory will hold, since i386
has alignof(uint64_t, double) == 4, but alignof(_Atomic(uint64_t)) ==
8, so MAXALIGN is not good enough.  I think atomics.h should probably
define MAXATOMICALIGN, or something like that.  I prototyped that,
which led me to pay attention to this __int128 (and typedef)
situation, where we went the other way and convinced the compiler to
underalign and generate different instructions to fit palloc().  (If
palloc were ever used for cross-thread allocation motivating atomic
storage, presumably i386 atomics would be an issue there too, but
let's ignore that for now...).  I guess today we could just do
palloc_aligned(sizeof(Int128AggState), alignof(Int128AggState),
MCXT_ALLOC_ZERO) for that, and let the compiler worry about the
__int128 and its containing struct?  I prototyped that and it seemed
vaguely plausible, though I can see the argument against it is "what
about when the type spreads and someone forgets?", but at first glance
it seems to be much more localised than the atomics/shmem problem.
IDK.

In a very quick hack (so probably missing things) I also seemed to be
able to get rid of all our ALIGNOF_ configure probes and just write
alignof(int) when I want the alignment of int, move the MAXALIGN
derivation into about two lines of c.h, and stuff alignof() inside the
right structs as you said...