Details
I'm concerned that the automated process pythonnet uses to generate the interop[version].cs file might be flawed. This is the relevant snippet from object.h
unsigned int tp_version_tag;
destructor tp_finalize;
vectorcallfunc tp_vectorcall;
/* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
this is how I mapped those fields in my handmade interop38.cs
public static int tp_version_tag = 0;
public static int tp_finalize = 0;
public static int tp_vectorcall = 0;
public static int tp_print = 0;
public static int am_await = 0;
but here's how the auto-generated interop38.cs maps them
public static int tp_version_tag = 0;
public static int tp_finalize = 0;
public static int tp_vectorcall = 0;
public static int am_await = 0;
Notice the missing public static int tp_print = 0;
I'm thinking that the Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int); messed up the auto-gen technique? Won't all fields following tp_vectorcall be offset incorrectly due to this?
Details
I'm concerned that the automated process pythonnet uses to generate the interop[version].cs file might be flawed. This is the relevant snippet from
object.hthis is how I mapped those fields in my handmade interop38.cs
but here's how the auto-generated interop38.cs maps them
Notice the missing public static int tp_print = 0;
I'm thinking that the
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);messed up the auto-gen technique? Won't all fields followingtp_vectorcallbe offset incorrectly due to this?