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 <1632775114.1.0.979208858986.issue15870@roundup.psfhosted.org>
In-reply-to
Content
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: https://godbolt.org/z/GYrfTqaGn  I am pretty sure this is out of compliance with C99.
History
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: <1632775114.1.0.979208858986.issue15870@roundup.psfhosted.org>
2021-09-27 20:38:34haberman2linkissue15870 messages
2021-09-27 20:38:33haberman2create