Here is another patch set to sprinkle some C11 features around the
code. My aim is to make a little bit of use of several C11 features
as examples and encouragement for future code, and to test compilers.
Here, I'm proposing to make some use of the alignas specifier. This
takes the place of compiler extensions such as
__attribute__((aligned(a))) and __declspec(align(a)), packaged up as
pg_attribute_aligned(a), which are used in a variety of places. Also,
we can simplify some places where unions are used to encourage
alignment, and remove a few workaround for lack of alignment attribute
support.
Some detail notes:
- Technically, compilers are only required to support alignas up to
(handwaving over some terminology) the largest alignment of a built-in
type, so maybe 8 or 16. Support for larger alignments like
alignas(PG_CACHE_LINE_SIZE) is implementation-defined. I have split up
my patches so that fundamental and extended alignments are in separate
patches, so this could be eased into, but I'm expecting that all
compilers in practical use support alignments up to PG_IO_ALIGN_SIZE.
(For MSVC, 4096 appears to be the actual limit by default, per [0], but
this is independent of using alignas or __declspec. I haven't found any
explicit documentation for clang or gcc.)
[0]:
https://learn.microsoft.com/en-us/cpp/build/reference/align-section-alignment?view=msvc-170
- 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. For
int128, there is no straightforward solution, so I'm also leaving that
as is.
(The reason for this restriction is that typedefs are supposed to be
type aliases that are interchangeable. But if you have two otherwise
compatible typedefs with different alignments, this kind of violates the
C type system and the compiler has to do some nonstandard magic to
handle this (or fail to, see "checking for __int128 alignment bug").)
- You cannot use alignas to underalign a type. So again, int128 cannot
be handled by this.
For at least these reasons, I'm leaving pg_attribute_aligned() and some
of its more tricky uses in place and unchanged.
