Correct size of allocated space for unbounded objects #987
Conversation
On 32 bit data models, there was an overflow due to an `unsigned long long` result cast into `size_t`, effectively preventing compilation on 32 bit systems.
|
Oops. Although, if |
|
@smowton I am not sure about this, before we had |
|
It doesn't actually allocate any memory, just interpreter address space. My concern is running out of address space, not memory. |
|
@smowton ok, then your proposal would be to use 64 bit interpreter address space on 32 bit systems, too? |
|
Yes re: using 64-bit interpreter addresses everywhere. Don't know about limits-- I picked 2^32 out of the air, but 2^16 seems likely to be routinely overflowed and 2^24 leaves rather few object addresses available on a 32-bit arch. |
|
@smowton @romainbrenguier do we agree that this should be done, but is not urgent to to 32 bit not being the main target architecture? |
|
Yes |
|
yes |
|
@mgudemann, rebase please |
|
@peterschrammel please note that we weill currently not fix this, as only 32 bit systems are affected |
|
@mgudemann @smowton actually I think travis runs tests on some 32 bits systems, so this problem could lead to failures on CI that are difficult to debug. Could we get this merged? If the size is still a problem, can we pick something 2^16 and 2^24 and add a note saying this is an arbitrary limit? |
|
Are you sure? I don't see any evidence of that in .travis.yml |
|
@smowton yes maybe you are right |
|
obsolete with #1484 |
On 32 bit data models, there was an overflow due to an
unsigned long longresult cast into
size_t, effectively preventing compilation on 32 bitsystems.