Author vstinner
Recipients Greg Price, aeros, malin, mark.dickinson, rhettinger, sir-sigurd, vstinner
Date 2019-09-18.07:50:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> We're wasted a lot of dev time on something that never promised much value in the first place.

I'm one of the first to advocate to replace ugly macros with clean static inline functions. Macros are evil and can be too easily misused.

On PR 15216, Benjamin and Raymond advised to replace the macro with a function.

I'm also a believer that one day, we could replace duplicated C functions accepting variant of C "integers" types with a single larger type:

* signed: replace (char, short, int, long, long long, ssize_t) with intmax_t
* unsigned: replace (unsigned char, unsigned short, unsigned int, unsigned long, unsigned long long, size_t) with uintmax_t

Sadly, it seems like such change has a small performance loss, and so cannot be done in "performance critical" code. I consider that longobject.c is such performance critical code.


I converted some macros of the Python C API to static inline functions, like Py_INCREF() or _PyObject_GC_TRACK():

Compared to macros, static inline functions have multiple advantages:

* Parameter types and return type are well defined;
* They don't have issues specific to macros: see GCC Macro Pitfals ;
* Variables have a well defined local scope ;
* GDB is able to retrieve then name when read the current C stack ("backtrace").


Again, I advice to add a small comment in longobject.c macros to explain that converting them to functions would loose performances.
Date User Action Args
2019-09-18 07:50:40vstinnersetrecipients: + vstinner, rhettinger, mark.dickinson, malin, Greg Price, sir-sigurd, aeros
2019-09-18 07:50:40vstinnersetmessageid: <>
2019-09-18 07:50:40vstinnerlinkissue37812 messages
2019-09-18 07:50:39vstinnercreate