It does not ensure alignment forPyUnicode_DATA(), it ensures alignment forstate.

To ensure alignment forPyUnicode_DATA(), you need to add_Py_ALIGN_AS before thedata field inPyUnicodeObject.

Am I missing something? This sounds like a distinction without a difference.

• ThePyUnicode_DATA() macro depends on the size ofPyASCIIObject.
• The size is a multiple of the alignment.
• The alignment ofPyASCIIObject must be at least the alignment of every member, so it must be at least 4 bytes with the_Py_ALIGN_AS(4) macro.

The alignment ofPyASCIIObject should be the same as the alignment of PyObject.

The definition of the_PyUnicode_COMPACT_DATA() macro and the code that calculates the size of thePyASCIIObject objects should be changed to guarantee the alignment of data.

Perhaps_Py_ALIGN_AS(4) should be added inPyObject_HEAD.

Huh? Why?

What exactly are you asking about?

Why? AFAIK, forsizeof(PyASCIIObject) it doesn't really matter.
I'd rather avoid setting a 4-byte alignment for 64-bit pointers.

FWIW, since 3.3 the header says "the data immediately follow the structure". We can't switch users to_Py_SIZE_ROUND_UP, we need to make sure the size is aligned.

The data immediately following the structure (PyASCIIObject or PyCompactUnicodeObject) has the same alignment as the structure. Adding_Py_ALIGN_AS() before thestate member does not change the alignment of the structure. If we add a byte at the end of the structure, the alignment of the data immediately following the structure will change. It works for current structures by accident, but we can just add padding for the same effect.

I'd rather avoid setting a 4-byte alignment for 64-bit pointers.

_Alignas(4) sets theminimum alignment -- it only makes the alignmentstricter. It won't reduce the alignment of 64-bit pointers.

Adding_Py_ALIGN_AS() before the state member does not change the alignment of the structure.

It does. Seehttps://gcc.godbolt.org/z/evh3hjxM8, for example. Arrays of structs (bothFoo arr[N] andmalloc(sizeof(Foo) * N)) would not work if that wasn't the case.

Hmm, it seems that the alignment of a structure is determined by the largest alignment of its members. I didn't find an explicit statement in the C11 standard, but it seems logical. If the structure has less alignment, then we can't guarantee the alignment of the members.

So we can apply _Py_ALIGN_AS() to any member, and it will work independently of the compiler.

The original issue (#63736) was because on some platformsPy_ssize_t and pointers have alignment less than 4.

Yeah.
FWIW, I also didn't find an explicit statement that structsize is a multiple of its alignment, but it's implied by the fact thatmalloc(sizeof(element_type) * n) allocates an array.

Hmm, it seems that the alignment of a structure is determined by the largest alignment of its members. I didn't find an explicit statement in the C11 standard, but it seems logical. If the structure has less alignment, then we can't guarantee the alignment of the members.

So we can apply _Py_ALIGN_AS() to any member, and it will work independently of the compiler.

The original issue (#63736) was because on some platformsPy_ssize_t and pointers have alignment less than 4.