At the moment, only snprintf pauses issues, but I presume that there are others similar cases.
Doing the following instead:
#define snprintf(...) _snprintf(__VA_ARGS__) #define vsnprintf(...) _vsnprintf(__VA_ARGS__)
would allow the client code to protect from macro expansion with parentheses when they need to. I think that it would be backward compatible.
On Thu, Apr 9, 2020 at 5:30 PM Victor Stinner email@example.com wrote:
Do you have issues with other macros than snprintf?
In pyerrors.h, I see:
#if defined(MS_WIN32) && !defined(HAVE_SNPRINTF) # define HAVE_SNPRINTF # define snprintf _snprintf # define vsnprintf _vsnprintf #endif
A minimum fix would be to not define these functions if __cplusplus__ macro is defined.
I suggest you to open an issue at https://bugs.python.org/
Le jeu. 9 avr. 2020 à 12:24, Sylvain Corlay firstname.lastname@example.org a écrit :
I hope I am not breaking any rules by posting here. I maintain a number
libraries and C++ Python extensions and one slightly annoying thing about the Python.h headers is that it includes headers defining macros such as *snprintf*.
In C++, this collides with std::snprintf defined in the <cstdio>. One backward-compatible way to make these collision less likely would be to make this macro a function-style macro - so that we could prevent the
expansion in client code by simply adding parentheses to the calls to the actual functions.
In my opinion, it would make the world a better place for C++ Python extension authors :)
Sylvain _______________________________________________ capi-sig mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org
-- Night gathers, and now my watch begins. It shall not end until my death.