This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients amaury.forgeotdarc, asvetlov, eric.smith, larry, loewis, mark.dickinson, meador.inge, pitrou, rhettinger, sdaoden, serhiy.storchaka, stutzbach, vstinner, xuanji
Date 2012-09-22.22:42:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Why is that permissible but _PyLong_IS_SMALL_INT is not?

It's *permissable* primarily because it is there. There are many places in Python which invoke undefined behavior already (most notably wrt. signed integers); we should strive to eliminate them.

OTOH, obmalloc clearly makes a lot of assumptions on the hardware architecture (including the assumption that there is page-based virtual memory, etc). It's a memory allocator, that gives permission to make such assumptions. If it turns out that they break on some system, obmalloc cannot be used there - hence usage of obmalloc is still a compile-time option.

In addition, for the specific macros: it's easy to see that a compiler may optimize _PyLong_IS_SMALL_INT as true by simple static analysis. For Py_ADDRESS_IN_RANGE, the same static analysis is not possible, since the memory doesn't come from a declared array. It would require whole-program analysis to determine that .address always points to a memory block with ARENA_SIZE bytes. If a compiler manages to figure it out, obmalloc cannot be used on that system (and if that happens, I'll recommend to drop or revise obmalloc altogether, perhaps in favor of a system pool allocator).
Date User Action Args
2012-09-22 22:42:56loewissetrecipients: + loewis, rhettinger, amaury.forgeotdarc, mark.dickinson, pitrou, vstinner, larry, eric.smith, stutzbach, asvetlov, meador.inge, xuanji, sdaoden, serhiy.storchaka
2012-09-22 22:42:56loewissetmessageid: <>
2012-09-22 22:42:55loewislinkissue10044 messages
2012-09-22 22:42:54loewiscreate