This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author haberman2
Recipients Alexander.Belopolsky, Arfrever, Christian.Tismer, Robin.Schreiber, amaury.forgeotdarc, belopolsky, haberman2, jcea, jhaberman, lekma, loewis, mattip, petr.viktorin, pitrou, seberg, steve.dower
Date 2021-09-27.20:38:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This behavior is covered by the standard.  The following C translation unit is valid according to C99:

  struct PyTypeObject;
  extern struct PyTypeObject Foo_Type;
  struct PyTypeObject *ptr = &Foo_Type;

Specifically, &Foo_Type is an "address constant" per the standard because it is a pointer to an object of static storage duration (6.6p9).

The Python docs contradict this with the following incorrect statement:

> However, the unary ‘&’ operator applied to a non-static variable like PyBaseObject_Type() is not required to produce an address constant.

This statement is incorrect:

1. PyBaseObject_Type is an object of static storage duration.  (Note, this is true even though it does not use the "static" keyword -- the "static" storage-class specifier and "static storage duration" are separate concepts).

2. It follows that &PyBaseObject_Type is required to produce an address constant. because it is a pointer to an object of static storage duration.

MSVC rejects this standard-conforming TU when __declspec(dllimport) is added:  I am pretty sure this is out of compliance with C99.
Date User Action Args
2021-09-27 20:38:34haberman2setrecipients: + haberman2, loewis, jcea, amaury.forgeotdarc, belopolsky, pitrou, Arfrever, petr.viktorin, lekma, Alexander.Belopolsky, mattip, Robin.Schreiber, steve.dower, seberg, Christian.Tismer, jhaberman
2021-09-27 20:38:34haberman2setmessageid: <>
2021-09-27 20:38:34haberman2linkissue15870 messages
2021-09-27 20:38:33haberman2create