[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread STINNER Victor
STINNER Victor added the comment: In short, I did my checks on my side, and the merged change now LGTM. Thanks Christian for fixing it ;-) -- ___ Python tracker ___

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread STINNER Victor
STINNER Victor added the comment: IMO making the assumption that "char" is signed or not in C code is bad. If Python has code like that, it must be signed to explicitly use one of these types: unsigned char or uint8_t, signed char or int8_t. Hopefully, Python can now use C99 since Python

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Christian Heimes
Christian Heimes added the comment: The fix is in all stable branches. Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Christian Heimes
Christian Heimes added the comment: New changeset 4371fbd4328781496f5f2c6938c4d9a84049b187 by Christian Heimes in branch '3.10': [3.10] bpo-46513: Remove AC_C_CHAR_UNSIGNED / __CHAR_UNSIGNED__ (GH-30851) (GH-30914)

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Christian Heimes
Christian Heimes added the comment: New changeset 04772cd6f164c1219c8c74d55626ba114f01aa96 by Christian Heimes in branch '3.9': [3.9] bpo-46513: Remove AC_C_CHAR_UNSIGNED / __CHAR_UNSIGNED__ (GH-30851) (GH-30915)

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Christian Heimes
Change by Christian Heimes : -- pull_requests: +29094 pull_request: https://github.com/python/cpython/pull/30915 ___ Python tracker ___

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Christian Heimes
Change by Christian Heimes : -- pull_requests: +29093 pull_request: https://github.com/python/cpython/pull/30914 ___ Python tracker ___

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread Petr Viktorin
Petr Viktorin added the comment: Yeah, that looks like it's for some long-forgotten compiler that didn't implement `signed char` at all. 1994 was a fun time, apparently. -- nosy: -miss-islington ___ Python tracker

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-26 Thread miss-islington
miss-islington added the comment: New changeset 6e5a193816e1bdf11f5fb78d620995fd6987ccf8 by Christian Heimes in branch 'main': bpo-46513: Remove AC_C_CHAR_UNSIGNED / __CHAR_UNSIGNED__ (GH-30851) https://github.com/python/cpython/commit/6e5a193816e1bdf11f5fb78d620995fd6987ccf8 --

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread STINNER Victor
STINNER Victor added the comment: My audioop.c change which looks to be wrong (useless): diff --git a/Modules/audioop.c b/Modules/audioop.c index 3aeb6f04f13..4c04b17ce7f 100644 --- a/Modules/audioop.c +++ b/Modules/audioop.c @@ -1948,6 +1941,13 @@ audioop_exec(PyObject* module) {

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread STINNER Victor
STINNER Victor added the comment: To test if a C type is signed or not, I wrote this macro: // Test if a C type is signed. // // Usage: assert(_Py_CTYPE_IS_SIGNED(char)); // fail if 'char' type is unsigned #define _Py_CTYPE_IS_SIGNED(T) (((T)-1) < 0) I planned to use it to raise an error on

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread STINNER Victor
STINNER Victor added the comment: > Modules/audioop.c uses __CHAR_UNSIGNED__, but the absence or presence of the > symbol does not affect behavior This comment is really weird since audioop explicitly uses "signed char" and "unsigned char". Maybe to avoid any risk of confusion, the C code

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread STINNER Victor
STINNER Victor added the comment: Fedora downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=2043555 We should make sure that Python can be built with -fsigned-char *and* with -funsigned-char: build Python, but also run its test suite. --

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread Christian Heimes
Christian Heimes added the comment: Modules/audioop.c uses __CHAR_UNSIGNED__, but the absence or presence of the symbol does not affect behavior: #if defined(__CHAR_UNSIGNED__) #if defined(signed) /* This module currently does not work on systems where only unsigned characters are

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread Christian Heimes
Change by Christian Heimes : -- keywords: +patch pull_requests: +29062 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30851 ___ Python tracker

[issue46513] AC_C_CHAR_UNSIGNED from configure.ac confuses GCC 12+ by defining __CHAR_UNSIGNED__

2022-01-25 Thread Miro Hrončok
New submission from Miro Hrončok : As described at https://mail.python.org/archives/list/python-...@python.org/thread/MPHZ3TGSHMSF7C4P7JEP2ZCYLRA3ERC5/ the AC_C_CHAR_UNSIGNED macro from configure.ac confuses GCC 12+ as it exports a reserved symbol __CHAR_UNSIGNED__ through pyconfig.h. My