Fix the signature of tp_new #687
Conversation
According to the docs, the signature of `tp_new` should be: `PyObject* tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)` https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new We don't care about the arguments, but according to the C standard 6.3.2.3.8 this is undefined behavior: > A pointer to a function of one type may be converted to a pointer to a > function of another type and back again; the result shall compare equal to > the original pointer. If a converted pointer is used to call a function whose > type is not compatible with the pointed-to type, the behavior is undefined. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=60 In normal platforms the behavior is to work as expected, but in WebAssembly, this crashes. Fixes pyodide/pyodide#5015.
hoodmane
force-pushed
the
tp_new-signature
branch
from
579a7e3
to
fcff84c
Compare
|
I wonder if we could add Pyodide tests to nanobind CI. |
|
We've got them in pybind11, so probably? |
|
The CI uses cmake directly and I was unable to figure out how to get it to stop saying:
So probably someone with a bit more cmake experience would have to do this. As an aside, I see that people on the internet suggest using |
|
@hoodmane I will give it a try in another PR |
|
FYI, in pybind11 I used scikit-build-core to make a |
|
Oops, that's not good. Thank you for finding and fixing this issue. I am open to including PyIodide in the test matrix—however, someone else would need to create a PR, I don't have the time to pursue this myself. |
According to the docs, the signature of `tp_new` should be: `PyObject* tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)` https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new We don't care about the arguments, but according to the C standard 6.3.2.3.8 this is undefined behavior: > A pointer to a function of one type may be converted to a pointer to a > function of another type and back again; the result shall compare equal to > the original pointer. If a converted pointer is used to call a function whose > type is not compatible with the pointed-to type, the behavior is undefined. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=60 In normal platforms the behavior is to work as expected, but in WebAssembly, this crashes. Fixes pyodide/pyodide#5015.
According to the docs, the signature of `tp_new` should be: `PyObject* tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)` https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new We don't care about the arguments, but according to the C standard 6.3.2.3.8 this is undefined behavior: > A pointer to a function of one type may be converted to a pointer to a > function of another type and back again; the result shall compare equal to > the original pointer. If a converted pointer is used to call a function whose > type is not compatible with the pointed-to type, the behavior is undefined. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=60 In normal platforms the behavior is to work as expected, but in WebAssembly, this crashes. Fixes pyodide/pyodide#5015.
According to the docs, the signature of
tp_newshould be:PyObject* tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)We don't care about the arguments, but according to the C standard clause 6.3.2.3.8 this is undefined behavior:
In normal platforms the behavior is to work as expected, but in WebAssembly, this crashes.
Fixes pyodide/pyodide#5015.
cc @henryiii @ryanking13