[Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c

"Martin v. Löwis" martin at v.loewis.de
Tue Jan 3 22:59:42 CET 2006


Tim Peters wrote:
>>Modified: python/branches/ssize_t/Objects/obmalloc.c
[...]
> This checkin should be reverted for now.

Not sure whether you've noticed this is "just" on the ssize_t branch.
Without this patch, it is not possible to allocate 4GiB or more for
a string object in debug mode, which kind of defeated my attempts to
test that.

I certainly plan to remove all XXX marks I have introduced in that
branch before suggesting to integrate it back into the trunk.

So "for now", I would prefer to keep it, and only revert it if
I have a complete fix.

> It's in
> _PyObject_DebugMalloc, and at present the layout of the extra debug
> info in a PYMALLOC_DEBUG build is hard-coded to use 4-byte fields, no
> matter what sizeof(size_t) may be.  One of the extra fields recorded
> in a PYMALLOC_DEBUG build is the number of bytes requested, and at
> present it's simply not capable of recording a value that doesn't fit
> in 4 bytes.

Well, AFAICT, it "works" even if it records only records the lower 4
bytes of the requested size. Upon freeing, it just won't put enough
DEADBYTEs in, which I cannot see having further unfortunate consequences
(except that it won't diagnose errors as good anymore as it could).

> Even after (if ever ;-)) this is changed to support recording 8-byte
> values on a box where sizeof(size_t) == 8, the "total < nbytes" part
> of the test would still be appropriate:  PyObject_DebugMalloc requests
> more memory (`total`) than the user asked for (`nbytes`), and the
> computation of `total` may have overflowed.  That's what "total <
> nbytes" is checking, and that's the right way to spell the overflow
> check on any box.

Certainly; I did not mean to completely disable this test.

Regards,
Martin


More information about the Python-checkins mailing list