* Martin v. Loewis, on 07.07.2010 21:10:
Python 3.1.1, file [pymem.h]:
PyAPI_FUNC(void *) PyMem_Malloc(size_t);
#define PyMem_MALLOC(n) (((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \
: malloc((n) ? (n) : 1))
The problem with the latter that it seems that it's intended for safety
but does the opposite...
Why do you say that? It certainly *does* achieve safety, wrt. to certain
errors, specifically:
- passing sizes that are out-of-range
- supporting malloc(0) on all systems
It uses malloc instead of PyMem_Malloc. malloc may well be different and use a
different heap in an extension DLL than in the Python interpreter and other
extensions. That's one thing that the docs (rightly) warn you about.
Perhaps (if it isn't intentional) this is a bug of the oversight type,
that nobody remembered to update the macro?
Update in what way?
I was guessing that at one time there was no PyMem_Malloc. And that it was
introduced to fix Windows-specific problems, but inadvertently without updating
the macro. It's just a guess as to reasons why the macro uses malloc directly.
Except for the problems with file descriptors I think a practical
interim solution for extensions implemented in C could be to just link
the runtime lib statically. For a minimal extension this increased the
size from 8 KiB to 49 KiB. And generally with MS tools the size is
acceptably small.
If you think that's fine for your extension module (which may well be
the case), go ahead.
I have no comment on that except pointing it out as a somewhat stupid, somewhat
evil social inclusion/exclusion argument, talking to the audience. Argh. You're
wasting my time. But anyway, 49 KiB is small by today's standards. For example,
you get 20 of those in a single MiB, and about 20.000 in a single GiB.
But then, you could also just link with a different
DLL version of the CRT instead.
When I wrote "link the runtime lib statically" that was an alternative to the
usual link-as-DLL.
It wouldn't make sense to link the runtime lib statically as an alternative to
linking it statically.
As for linking to a different /version/ of the CRT, if you really mean that, I
think that's difficult. It's not necessarily impossible, after all there's
STLPort. But I think that it must at the very least be rather difficult to do
with Microsoft's tools, for otherwise people would have employed that solution
before, and so I wouldn't trust the result, and wouldn't waste the time trying.
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list
