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 <1648717184.73.0.9591468393.issue47179@roundup.psfhosted.org>
In-reply-to
Content
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: https://foss.heptapod.net/pypy/cffi/-/issues/531#note_181779

[max_align_t]: https://en.cppreference.com/w/c/types/max_align_t

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