projects / OpenSPARC-T2-DV / blame
| Commit | Line | Data |
|---|---|---|
| 86530b38 AT |
1 | #ifndef Py_PYMEM_H |
| 2 | #define Py_PYMEM_H | |
| 3 | ||
| 4 | #include "pyport.h" | |
| 5 | ||
| 6 | #ifdef __cplusplus | |
| 7 | extern "C" { | |
| 8 | #endif | |
| 9 | ||
| 10 | /* BEWARE: | |
| 11 | ||
| 12 | Each interface exports both functions and macros. Extension modules should | |
| 13 | use the functions, to ensure binary compatibility across Python versions. | |
| 14 | Because the Python implementation is free to change internal details, and | |
| 15 | the macros may (or may not) expose details for speed, if you do use the | |
| 16 | macros you must recompile your extensions with each Python release. | |
| 17 | ||
| 18 | Never mix calls to PyMem_ with calls to the platform malloc/realloc/ | |
| 19 | calloc/free. For example, on Windows different DLLs may end up using | |
| 20 | different heaps, and if you use PyMem_Malloc you'll get the memory from the | |
| 21 | heap used by the Python DLL; it could be a disaster if you free()'ed that | |
| 22 | directly in your own extension. Using PyMem_Free instead ensures Python | |
| 23 | can return the memory to the proper heap. As another example, in | |
| 24 | PYMALLOC_DEBUG mode, Python wraps all calls to all PyMem_ and PyObject_ | |
| 25 | memory functions in special debugging wrappers that add additional | |
| 26 | debugging info to dynamic memory blocks. The system routines have no idea | |
| 27 | what to do with that stuff, and the Python wrappers have no idea what to do | |
| 28 | with raw blocks obtained directly by the system routines then. | |
| 29 | */ | |
| 30 | ||
| 31 | /* | |
| 32 | * Raw memory interface | |
| 33 | * ==================== | |
| 34 | */ | |
| 35 | ||
| 36 | /* Functions | |
| 37 | ||
| 38 | Functions supplying platform-independent semantics for malloc/realloc/ | |
| 39 | free. These functions make sure that allocating 0 bytes returns a distinct | |
| 40 | non-NULL pointer (whenever possible -- if we're flat out of memory, NULL | |
| 41 | may be returned), even if the platform malloc and realloc don't. | |
| 42 | Returned pointers must be checked for NULL explicitly. No action is | |
| 43 | performed on failure (no exception is set, no warning is printed, etc). | |
| 44 | */ | |
| 45 | ||
| 46 | PyAPI_FUNC(void *) PyMem_Malloc(size_t); | |
| 47 | PyAPI_FUNC(void *) PyMem_Realloc(void *, size_t); | |
| 48 | PyAPI_FUNC(void) PyMem_Free(void *); | |
| 49 | ||
| 50 | /* Starting from Python 1.6, the wrappers Py_{Malloc,Realloc,Free} are | |
| 51 | no longer supported. They used to call PyErr_NoMemory() on failure. */ | |
| 52 | ||
| 53 | /* Macros. */ | |
| 54 | #ifdef PYMALLOC_DEBUG | |
| 55 | /* Redirect all memory operations to Python's debugging allocator. */ | |
| 56 | #define PyMem_MALLOC PyObject_MALLOC | |
| 57 | #define PyMem_REALLOC PyObject_REALLOC | |
| 58 | ||
| 59 | #else /* ! PYMALLOC_DEBUG */ | |
| 60 | ||
| 61 | /* PyMem_MALLOC(0) means malloc(1). Some systems would return NULL | |
| 62 | for malloc(0), which would be treated as an error. Some platforms | |
| 63 | would return a pointer with no memory behind it, which would break | |
| 64 | pymalloc. To solve these problems, allocate an extra byte. */ | |
| 65 | #define PyMem_MALLOC(n) malloc((n) ? (n) : 1) | |
| 66 | #define PyMem_REALLOC(p, n) realloc((p), (n) ? (n) : 1) | |
| 67 | ||
| 68 | #endif /* PYMALLOC_DEBUG */ | |
| 69 | ||
| 70 | /* In order to avoid breaking old code mixing PyObject_{New, NEW} with | |
| 71 | PyMem_{Del, DEL} and PyMem_{Free, FREE}, the PyMem "release memory" | |
| 72 | functions have to be redirected to the object deallocator. */ | |
| 73 | #define PyMem_FREE PyObject_FREE | |
| 74 | ||
| 75 | /* | |
| 76 | * Type-oriented memory interface | |
| 77 | * ============================== | |
| 78 | * | |
| 79 | * These are carried along for historical reasons. There's rarely a good | |
| 80 | * reason to use them anymore (you can just as easily do the multiply and | |
| 81 | * cast yourself). | |
| 82 | */ | |
| 83 | ||
| 84 | #define PyMem_New(type, n) \ | |
| 85 | ( (type *) PyMem_Malloc((n) * sizeof(type)) ) | |
| 86 | #define PyMem_NEW(type, n) \ | |
| 87 | ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) | |
| 88 | ||
| 89 | #define PyMem_Resize(p, type, n) \ | |
| 90 | ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) | |
| 91 | #define PyMem_RESIZE(p, type, n) \ | |
| 92 | ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) | |
| 93 | ||
| 94 | /* In order to avoid breaking old code mixing PyObject_{New, NEW} with | |
| 95 | PyMem_{Del, DEL} and PyMem_{Free, FREE}, the PyMem "release memory" | |
| 96 | functions have to be redirected to the object deallocator. */ | |
| 97 | #define PyMem_Del PyObject_Free | |
| 98 | #define PyMem_DEL PyObject_FREE | |
| 99 | ||
| 100 | #ifdef __cplusplus | |
| 101 | } | |
| 102 | #endif | |
| 103 | ||
| 104 | #endif /* !Py_PYMEM_H */ |