This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author petr.viktorin
Recipients methane, petr.viktorin, pitrou, vstinner
Date 2022-03-31.08:59:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
malloc() returns memory that's "suitably aligned for any built-in type".
All of Python's allocation functions should do the same. 

In bpo-27987 (PR-12850, PR-13336), the alignment was raised* to 16 bytes and `long double`. This is OK for current architectures, so there is no practical issue right now.

But, C11 defines a [max_align_t] type which sounds like the *correct* thing to use for determining pymalloc/PyGC_Head alignment.
At least we should assert that obmalloc's ALIGNMENT is a multiple of `alignof(max_align_t)`, and use max_align_t rather than `long double` in PyGC_Head.

See also this python-cffi issue:


* (on 64-bit arches)
Date User Action Args
2022-03-31 08:59:44petr.viktorinsetrecipients: + petr.viktorin, pitrou, vstinner, methane
2022-03-31 08:59:44petr.viktorinsetmessageid: <>
2022-03-31 08:59:44petr.viktorinlinkissue47179 messages
2022-03-31 08:59:44petr.viktorincreate