GeezerVison

Why _Py_NO_INLINE?

This is the slow path. We want to make sure the fast path is inlined.

If we are going to take pointers to arbitrary places in memory, doesn't the standard require that those must be aligned? How are we making sure that all pointers to this region are aligned?. From the standard:

A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined.

Many compilers normally assume aligned pointer access.

Why do you think the returned memory would be unaligned?
How is this any different from malloc?

Why do you think the returned memory would be unaligned?

My question is not if the returned memory would be unaligned, but if we are taking pointers to random places of the chunk array. For instance, if we are doing anything isomorphic to this:

        data = (char *)malloc(16);
        sp1 = (short*)(data+3);

then we are doing it wrong. I am asking not because I think we are doing it wrong, but because i am still wrapping around the structure you have in mind for the chunks, because there is 3 or 4 layers of indirections, a "chunk struct" and at least 3 pointer accesses when pushin frames, so immediately I am wondering if this mechanism is taking this correctly.

I compiled Python with the undefined behavior sanitizer and it doesn't complain, so seems that there is no problem here.

On contrast, my example shows:

example.c:1313:30: runtime error: load of misaligned address 0x55f1ba0cd283 for type 'short int', which requires 2 byte alignment
0x55f1ba0cd283: note: pointer points here
 00  3d 0e 0b e5 f4 55 00 00  00 00 00 00 00 00 00 00  09 09 49 42 4d 39 30 36  21 00 00 00 00 00 00

On the other hand it found this (unrelated to this PR):

home/pablogsal/github/python/main/Modules/_sha3/kcp/KeccakP-1600-opt64.c:467:9: runtime error: load of misaligned address 0x563579d3c3f7 for type 'UINT64', whic
h requires 8 byte alignment
0x563579d3c3f7: note: pointer points here
 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23
             ^
/home/pablogsal/github/python/main/Modules/_sha3/kcp/KeccakP-1600-opt64.c:467:9: runtime error: load of misaligned address 0x563579d3c3ff for type 'UINT64', whic
h requires 8 byte alignment
0x563579d3c3ff: note: pointer points here
 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23
             ^
/home/pablogsal/github/python/main/Modules/_sha3/kcp/KeccakP-1600-opt64.c:467:9: runtime error: load of misaligned address 0x563579d3c407 for type 'UINT64', whic
h requires 8 byte alignment
0x563579d3c407: note: pointer points here
 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23
             ^
/home/pablogsal/github/python/main/Modules/_sha3/kcp/KeccakP-1600-opt64.c:467:9: runtime error: load of misaligned address 0x563579d3c40f for type 'UINT64', whic
h requires 8 byte alignment
0x563579d3c40f: note: pointer points here
 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23 23 23 23 23 23  23 23 23
             ^

I will open an issue

I am missing anything here?

No. It's just a hint to the reader that data is an array within the chunk.
chunk->data looks like a pointer deference, but &chunk->data[0] hints that this is an address calculation.

I’m curious why this one is included with <> when all the headers above use ""
(I don’t know much C note!)