STINNER Victor <vstin...@python.org> added the comment:
There are multiple good reasons to replace macros with static inline functions: * Parameter types and return value are well defined * Less error-prone: avoid completely https://gcc.gnu.org/onlinedocs/gcc-9.3.0/cpp/Macro-Pitfalls.html#Macro-Pitfalls * Variables have a well defined scope, reduce the risk of unexpected side effects I merged the PR 19017: it uses better names for the function and it adds assert(state != NULL). Be careful of bpo-39824: in some cases, the module state *can* be NULL: but I checked, and it's not the case here. Moreover, bpo-39824 may prevent NULL module state (let's see ;-)). Thanks Hai Shi! > minor disadvantage in code generation Micro-benchmarks and machine code analysis was done in previous issues replacing macros with static inline functions, and the outcome is that there is no effect on performance. See for example bpo-35059: performance critical Py_INCREF() and Py_DECREF() functions are now static inline functions. If someone is curious about the the machine code, you should use -O3 with PGO+LTO, which is what should be used on Linux distributions. If static inline functions are not inlined for whatever reason, I suggest to tune the compiler rather than moving back to ugly macros. If you use configure --enable-shared, I now also strongly suggest to use -fno-semantic-interposition: it's now used on Fedora and RHEL to build Python libpython. Note: Support for "static inline" is now explicitly required by the PEP 7 to build Python, since Python 3.6. And it's more and more used in Python header files. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39968> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
