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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com