Eryk Sun added the comment:
The ctypes issue is bpo-12836, which has a suggested solution. This issue is a
third-party problem introduced by a workaround, which needs to be addressed at
the source, such as with helper functions and subclasses that close the loop.
--
resolution: ->
Ian M. Hoffman added the comment:
I agree with you. When I wrote "desired behavior" I intended it to mean "my
selfishly desired outcome of not loading my struct with a dangling pointer."
This issue seems to have descended into workarounds that treat the symptoms;
I'm all for treating the
Eryk Sun added the comment:
> `data_as` method which has the desired behavior: "The returned
> pointer will keep a reference to the array."
I don't think it's the desired behavior at all. data_as() sets an _arr
attribute of which ctypes isn't aware. It should cast the address to the given
Ian M. Hoffman added the comment:
You are correct.
After further review, I found an older ctypes issue #12836 which was then
enshrined in a workaround in the numpy.ndarray.ctypes interface to vanilla
ctypes.
https://numpy.org/doc/stable/reference/generated/numpy.ndarray.ctypes.html
Numpy
Eryk Sun added the comment:
I think this is a numpy issue. Its data_as() method doesn't support the ctypes
_objects protocol to keep the numpy array referenced by subsequently created
ctypes objects. For example:
import ctypes
import numpy as np
dtype = ctypes.c_double
New submission from Ian M. Hoffman :
A description of the problem, complete example code for reproducing it, and a
work-around are available on SO at the link:
https://stackoverflow.com/questions/64083376/python-memory-corruption-after-successful-return-from-a-ctypes-foreign-function
In
