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 pablogsal
Recipients corona10, erlendaasland, pablogsal, rhettinger, vstinner
Date 2021-03-17.00:00:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615939223.9.0.46992109746.issue43502@roundup.psfhosted.org>
In-reply-to
Content
I agree we should be careful here. There are several things to consider:

* Macros transformed into function may or may not get inlined so there is a risk of affecting performance if we just transform them in bulk.

* Because the macro is defined as 'static inline' in the header file, then it *can* be inlined everywhere if the compiled decides to do it. It will be one copy symbol in the text segment on every compilation unit. Notice that 'inline' has a special meaning in C99 and it doesn't only mean "inline this function". It has visibility implications (see section 6.7.4 of the C99 standard).

* There is risk to introducing a backwards-incompatible ABI change by mistake as Victor mentions.

* This can affect also the link patterns of extension modules because these symbols may be visible in the resulting binaries when they were macro-level-inlined before. I cannot see any problem that can happen because of this but we should carefully consider it.

In short, there is the value of converting these macros for extra type safety, but we need to at the very least be very careful and if we decide to go forward this needs as many reviews as possible so we don't miss anything. I would recommend maybe start a thread about this in python-dev.
History
Date User Action Args
2021-03-17 00:00:23pablogsalsetrecipients: + pablogsal, rhettinger, vstinner, corona10, erlendaasland
2021-03-17 00:00:23pablogsalsetmessageid: <1615939223.9.0.46992109746.issue43502@roundup.psfhosted.org>
2021-03-17 00:00:23pablogsallinkissue43502 messages
2021-03-17 00:00:23pablogsalcreate