Repository navigation
__sizeof__ underreports size of 0 by 4 bytes #98159
Description
Bug report
sys.getsizeof and int#__sizeof__() both underreport the size of the 0 singleton by 4 bytes, due to _PyLong_DIGIT_INIT setting ob_size to 0 when initializing the 0 singleton, the correct value should be 1, since there is a single ob_digit stored, as I understand it.
Examples:
Python 3.10.7 (main, Sep 15 2022, 01:51:29) [Clang 14.0.0 (clang-1400.0.29.102)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(0)
24
>>> sys.getsizeof(1)
28Python 3.8.14 (default, Sep 6 2022, 23:26:50)
[Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(0)
24
>>> sys.getsizeof(1)
28Details
_PyLong_DIGIT_INIT(val)is used to initialize an immortalPyVarObject.- Depending on the
valpassed it sets the theob_sizefield of the immortal using the expression:((val) == 0 ? 0 : ((val) > 0 ? 1 : -1))
2.1. Whenvalis0, this creates an_PyVarObject_IMMORTAL_INIT(&PyLong_Type, 0), which sets the underlyingPyVarObject'sob_sizeto0. int___sizeof___implusesob_size(throughPy_SIZE) to calculate the size- The
ob_sizeshould be1becauseob_digithas onedigitstored.
4.1. However,ob_sizeis set to0, and this contributes to under-reporting the size of0by thesizeof(digit)which is4
Your environment
- CPython versions tested on:
3.8.14,3.10.7 - Operating system and architecture:
Darwin 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27 PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_6
Activity
envp commentedon Oct 10, 2022
I'm not entirely sure if this behaviour is incorrect, but my understanding is that
ob_sizeshould count the singledigitstored inob_digit. That is my premise for filing this as a bug.Compiler explorer link: https://godbolt.org/z/rx7PbEYxd
corona10 commentedon Nov 6, 2022
This behavior looks like have a long history,
but the first trigger was from 36820dd by @mdickinson
@mdickinson
By this patch, The zero was set to
Py_SIZE(v) = 0;since the sign is zero, was this intended? or it should be fixed to have ob_size = 1 even if the sign is 0?corona10 commentedon Nov 6, 2022
@envp See also: #69408
mdickinson commentedon Nov 6, 2022
Definitely not:
ob_size=0is the correct value for a zero; IIRC, there are a good few places in the code that expectob_size=0for zero.And yes, it's true that
sys.getsizeofsometimes underreports for ints; that effect isn't limited to zero - there are lots of places inlongobject.cwhere we allocate enough space and then don't reallocate after normalisation. That's a deliberate choice.corona10 commentedon Nov 6, 2022
Thanks, Mark, I will close the issue.
The behavior looks like be intended.
cc @envp
envp commentedon Jan 4, 2023
Thanks Mark! That rationale definitely cleared it up for me.