[Python-Dev] Activating pymalloc (original) (raw)

Tim Peters tim.one@comcast.net
Fri, 15 Mar 2002 15:46:43 -0500

[Tim]

but the crucial phrase "the same memory API family" is left undefined.

[martin@v.loewis.de]

I always thought the notion of a "memory API family" is fairly obvious - none of those families has more than three members.

How do you know? The phrase simply isn't defined. "Fairly obvious" isn't reference-doc quality, and I clearly disagreed the first time around that "it's obvious". That means it isn't .

There is always one for allocation and one for deallocation, and perhaps one for reallocation. That's it.

Perhaps.

Like, are the functions and macros interchangeable?

Of course not. You use the macros for efficiency, accepting that you incorporate the implementation in your code, which results in a depenency between the binary extension module and the binary Python installation.

I wasn't talking about efficiency or binary compatibility, just about what (exactly) constitutes "same memory API family" (which, BTW, belongs in the reference docs proper, not in the middle of a page of examples).

For example, if you know something was allocated via PyMemMalloc, is it OK to release it via PyMemFREE? I simply can't guess from what the docs say, again because what constitutes "a family" is left undefined.

If you buy the notion of memory API families,

I'd be delighted to, if the concept were spelled out.

you cannot deallocate the things this way. ... Of course, you will get away with mixing the macro and non-macro versions, at least if you are not crossing Python version boundaries. Do that and you are on your own, though (if desired, Python could easily guarantee that you can mix APIs in this way, but I see no need for that guarantee).

I see nothing in the docs either forbidding or allowing such mixture; your view relies on the personal understanding of "memory API family" you've fought your way to after making a focused study of the source code. Extension authors aren't so conscientious, although I expect some have picked up by now that all the macro forms have been "deprecated" outside the core.

... If I can get the TeX to create a table for me, I'll see whether I can produce a table. More likely, Fred will have to fix it...

That would be great. Fred can do this from a plain text table with ease -- wrestling with TeX shouldn't stand in the way.

The endless layers of indirection macros make this quite a pain

I'm also uncomfortable with those. Fortunately, the family of the "object allocator" does not deserve being documented - I doubt anybody will ever need this. Also, the overriding hooks for replacing the function names and signatures don't need to be documented.

Agreed.

Which API?

PyObjectMALLOC/REALLOC/FREE, and PyCore* (both object and raw).

Gotcha.

In the Python source, the thread implementations use malloc and free on purpose, but it also turns up a curious > > free((char *)PyFileSystemDefaultEncoding); [...] Does that mean that, on Windows, we may free() a static char*?!

Of course not. This is wrapped in

#if defined(HAVELANGINFOH) && defined(CODESET) neither of which is defined on Windows.

As I said, it's worthy of a comment. I have no idea whether HAVE_LANGINFO_H and/or CODESET are defined on Windows. If the correctness of this code relies on that they're not defined on Windows (as it still appears it does), an "#if Windows ... #error" would even be appropriate.