GH-125174: Mark objects as statically allocated. #127797
Conversation
|
Out of curiosity, how disruptive is adding a new field to the object structure? |
It doesn't change the size of the |
markshannon
force-pushed
the
refcnt-with-flags
branch
from
0e7513a to
3788c60
Compare
|
This appears to be causing lots of compiler warnings on Windows. Here's what the "Files changed tab looks like on this PR: These warnings are now showing up on the "files changed" tab on every PR |
| #if SIZEOF_VOID_P > 4 | ||
| /* If an object has been freed, it will have a negative full refcnt | ||
| * If it has not it been freed, will have a very large refcnt */ | ||
| if (op->ob_refcnt_full <= 0 || op->ob_refcnt > (UINT32_MAX - (1<<20))) { |
There was a problem hiding this comment.
Apparently UINT32_MAX is not defined in all builds, so this breaks a buildbot.
There was a problem hiding this comment.
We use UINT32_MAX all over the place, so it must be defined. Maybe we're missing a #include somewhere.
There was a problem hiding this comment.
Looks like it's a C++ build that failing, which might explain it
* Set a bit in the unused part of the refcount on 64 bit machines and the free-threaded build. * Use the top of the refcount range on 32 bit machines
5 participants
This PR is a follow up to #125251 which made checking for immortal objects more robust.
This adds the ability to check whether objects are statically allocated or not, which should assist finalization and safety checks.