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.

Best,

On Thu, Apr 9, 2020 at 5:30 PM Victor Stinner vstinner@python.org wrote:

Hi,

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/

Victor

Le jeu. 9 avr. 2020 à 12:24, Sylvain Corlay sylvain.corlay@gmail.com a écrit :

...

Hi All,

I hope I am not breaking any rules by posting here. I maintain a number

of

...

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 macro expansion in client code by simply adding parentheses to the calls to the actual functions.

(std::snprintf)(foobar)

In my opinion, it would make the world a better place for C++ Python extension authors :)

Best,

Sylvain

---

capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org

-- Night gathers, and now my watch begins. It shall not end until my death.

Let's be simpler: what not put those definitions in a private header? There's no need to expose them to third-party code.

Regards

Antoine.

Le 09/04/2020 à 17:50, Victor Stinner a écrit :

Is "#define snprintf(...)" syntax supported by C99? Since Python 3.6, Python requires a sub-set of C99: https://www.python.org/dev/peps/pep-0007/#c-dialect

By the way, Python code base still uses:

#ifdef HAVE_STDARG_PROTOTYPES va_start(vargs, format); #else va_start(vargs); #endif

I'm not sure if we still need to support platforms which don't accept a second parameter to va_start().

Victor

Le jeu. 9 avr. 2020 à 17:38, Sylvain Corlay sylvain.corlay@gmail.com a écrit :

...

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.

Best,

On Thu, Apr 9, 2020 at 5:30 PM Victor Stinner vstinner@python.org wrote:

...

Hi,

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/

Victor

Le jeu. 9 avr. 2020 à 12:24, Sylvain Corlay sylvain.corlay@gmail.com a écrit :

...

Hi All,

I hope I am not breaking any rules by posting here. I maintain a number of 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 macro expansion in client code by simply adding parentheses to the calls to the actual functions.

(std::snprintf)(foobar)

In my opinion, it would make the world a better place for C++ Python extension authors :)

Best,

Sylvain

---

capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org

-- Night gathers, and now my watch begins. It shall not end until my death.

Is "#define snprintf(...)" syntax supported by C99? Since Python 3.6

This is a C preprocessor feature, not C++, so I would be surprised that it is not supported.

Let's be simpler: what not put those definitions in a private header? ... Python should use PyOS_snprintf instead where possible.

I agree. My proposed fix was just in case people relied on this macro (by calling it), to be backward compatible.

This fix would still break people who used the macro to refer to a function pointer though - but I find this incredibly unlikely.

S.

On Thu, Apr 9, 2020 at 8:06 PM Petr Viktorin encukou@gmail.com wrote:

On 2020-04-09 12:23, Sylvain Corlay wrote:

...

Hi All,

I hope I am not breaking any rules by posting here. I maintain a number of 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 macro expansion in client code by simply adding parentheses to the calls to the actual functions.

(std::snprintf)(foobar)

In my opinion, it would make the world a better place for C++ Python extension authors :)

This is already reported: https://bugs.python.org/issue36020

Python should use PyOS_snprintf instead where possible.

(Unfortunately I don't currently have time to work on this.)

---

capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org