Passing a memory address (pointer) to an extension?
robert.kern at gmail.com
Thu Oct 23 02:33:23 CEST 2008
Philip Semanchuk wrote:
> I'm writing a Python extension in C that wraps a function which takes a
> void * as a parameter. (The function is shmat() which attaches a chunk
> of shared memory to the process at the address supplied by the caller.)
> I would like to expose this function to Python, but I don't know how to
> define the interface.
> Specifically, when calling PyArg_ParseTuple(), what letter should I use
> to represent the pointer in the format string? The best idea I can come
> up with is to use a long and then cast it to a void *, but assuming that
> a long is big enough to store a void * is a shaky assumption. I could
> use a long long (technically still risky, but practically probably OK)
> but I'm not sure how widespread long longs are.
I recommend not giving the user access to that argument. Just use NULL and let
shmat() pick a starting address. I don't think it's really safe to let the user
pick, even in C. Perhaps if you're doing *really* low level stuff. Of course,
being that low level seems to be the point of posix_ipc, so maybe I should let
you get on with it. Anyways, the format "n" in Python >= 2.5 will correspond to
a Py_ssize_t integer, which will always be the size of a pointer.
You can return the void* that you get from shmat() with a PyCPointer object or
make a new, small type that encapsulates a pointer attached via shmat(). The
benefit of a real type is that you can type-check the input to shmdt() for
safety. I strongly recommend either of those approaches over returning an integer.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Python-list