STINNER Victor <[email protected]> added the comment:
> Is it at all possible to considering making some of this public API?
In bpo-35081, I wanted to move PyGC macros to the internal C API because they
are private functions, but also because they expose implementation details.
Example:
#define _PyGC_PREV_MASK_FINALIZED (1)
#define _PyGCHead_FINALIZED(g) \
(((g)->_gc_prev & _PyGC_PREV_MASK_FINALIZED) != 0)
#define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
#define _PyGC_FINALIZED(o) \
_PyGCHead_FINALIZED(_Py_AS_GC(o))
_Py_AS_GC(o) emits machine code which hardcodes the size and alignment of the
PyGC_Head structure. If PyGC_Head is changed, machine code will crash or
misbehave at least. And that happened recently: bpo-27987 changed PyGC_Head
between Python 3.7.4 and 3.7.5 with commit
8766cb74e186d3820db0a855ccd780d6d84461f7.
I'm not against exposing the "feature" in the public C API. I'm only against
exposing macros which "leak" implementation details. What I did recently is to
add regular functions in the public C API, and keep macros and static inline
functions for the internal C API.
We can for example add "int PyGC_Finalized(PyObject *obj);" function which
would be opaque in term of ABI.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue40240>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
