[issue16086] tp_flags: Undefined behaviour with 32 bits long

STINNER Victor report at bugs.python.org
Mon Oct 1 16:51:41 CEST 2012


STINNER Victor added the comment:

tp_flags type is long, not int.
Le 1 oct. 2012 16:42, "Martin v. Löwis" <report at bugs.python.org> a écrit :

>
> Martin v. Löwis added the comment:
>
> What matters is that precompiled stay compatible; in addition, existing
> source code should continue to compile unmodified.
>
> In the specific case, the flags type also shows up in PyType_Spec. As a
> consequence, the actual TPFLAGS_ values *do* constitute a part of the API.
>
> OTOH, a number of the flags are not considered part of the API at all
> (unfortunately, they aren't explicitly excluded, either). Before we make
> such a change, we should really declare what flags are meant to be by an
> extension module, and what flags are implementation details only to be used
> by the object runtime itself.
>
> Wrt. the proposed change: changing tp_flags to unsigned int is fine. I
> cannot see any real problem with changing PyType_Spec.flags to unsigned int
> - changing it to unsigned long would be incompatible on some systems.
>
> Wrt. changing the existing flags: I'd prefer some deprecation procedure
> that just bans them from being used in an extension module (ultimately
> wrapping them within Py_BUILD_CORE). Once they are deprecated, changing
> their type is clearly fine.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16086>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16086>
_______________________________________


More information about the Python-bugs-list mailing list