Author vstinner
Recipients Eric Cousineau, pablogsal, pitrou, vstinner
Date 2020-04-09.15:27:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586446071.53.0.288125605669.issue40240@roundup.psfhosted.org>
In-reply-to
Content
> 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.
History
Date User Action Args
2020-04-09 15:27:51vstinnersetrecipients: + vstinner, pitrou, pablogsal, Eric Cousineau
2020-04-09 15:27:51vstinnersetmessageid: <1586446071.53.0.288125605669.issue40240@roundup.psfhosted.org>
2020-04-09 15:27:51vstinnerlinkissue40240 messages
2020-04-09 15:27:51vstinnercreate