Bug 2043555

This seems to come from the configure.ac AC_C_CHAR_UNSIGNED macro that has been there since Python 1.2. Previously, it was a configure.in AC_CHAR_UNSIGNED macro since at least Python 1.0.

I am not quite sure what's wrong with that or what should be done to avoid that.

https://mail.gnu.org/archive/html/autoconf/2008-06/msg00056.html

I guess we could just drop AC_C_CHAR_UNSIGNED entirely?

For GCC/clang/ICC certainly, e.g. GCC 3.2 certainly predefines it and so does current version of clang.
But even if you keep it, you should filter it out from the pyconfig headers that are installed, because it overrides changes from the command line when using those headers.

Arguably, it might be a good idea if autoconf for it checks whether the specified compiler supports -fsigned-char and -funsigned-char options and whether
__CHAR_UNSIGNED__ is predefined in the latter and not predefined in the former case and whether for the default case it matches the auto-detected case,
and if so, leave the macro undefined because the compiler handles it, so there is no point overriding it explicitly.

> For GCC/clang/ICC certainly, e.g. GCC 3.2 certainly predefines it and so does current version of clang.

Well, I guess we can submit a dirty downstream-only modification if this is indeed urgent. But I think this needs to be fixed in autotools.

On my Fedora 35, /usr/include/python3.10/pyconfig-64.h contains:
---
/* Define to 1 if type `char' is unsigned and you are not using gcc.  */
#ifndef __CHAR_UNSIGNED__
/* # undef __CHAR_UNSIGNED__ */
#endif
---

I see that you build C++ code using -fsigned-char.

I didn't know -fsigned-char and -funsigned-char options of GCC.

I don't know if Python itself can be built with char declared as unsigned (-funsigned-char). I suppose that most code expects 'char' type to be signed.

But the public Python C API should not be affected by these options.

> https://mail.gnu.org/archive/html/autoconf/2008-06/msg00056.html

Q: "What's the point of the AC_C_CHAR_UNSIGNED macro?"
A: "If the C type `char' is unsigned, define `__CHAR_UNSIGNED__', unless the C compiler predefines it."

The __CHAR_UNSIGNED__ macro is used in a single C file in Python, Modules/audioop.c.
---
#if defined(__CHAR_UNSIGNED__)
#if defined(signed)
/* This module currently does not work on systems where only unsigned
   characters are available.  Take it out of Setup.  Sorry. */
#endif
#endif
---

audioop.c prefers "signed char" and "unsigned char" over "char". Maybe it should even use int8_t and uint8_t instead to avoid any risk of mistake.

Since Python doesn't use __CHAR_UNSIGNED__ (audioop.c can be fixed, if needed), IMO "AC_C_CHAR_UNSIGNED" can be removed from configure.ac, and so from pyconfig.h.

(In reply to Victor Stinner from comment #6)
> On my Fedora 35, /usr/include/python3.10/pyconfig-64.h contains:
> ---
> /* Define to 1 if type `char' is unsigned and you are not using gcc.  */
> #ifndef __CHAR_UNSIGNED__
> /* # undef __CHAR_UNSIGNED__ */
> #endif
> ---

On x86_64.

On aarch64, ppc64le, and s390x it's:
...
/* Define to 1 if type `char' is unsigned and your compiler does not
   predefine this macro.  */
#ifndef __CHAR_UNSIGNED__
# define __CHAR_UNSIGNED__ 1
#endif
...

(In reply to Jakub Jelinek from comment #4)
> Arguably, it might be a good idea if autoconf for it checks whether the
> specified compiler supports -fsigned-char and -funsigned-char options and
> whether
> __CHAR_UNSIGNED__ is predefined in the latter and not predefined in the
> former case and whether for the default case it matches the auto-detected
> case,
> and if so, leave the macro undefined because the compiler handles it, so
> there is no point overriding it explicitly.

That looks fairly complicated for a macro that is documented as unnecessary by the autotools doc.
They considered obsoleting it 14 years ago, but didn't do so for various reasons, and preferred marking it as "basically, don't use it".

I'll see if I can do something about this, but I'd recommend to get rid of it on your side if you can do so.

https://mail.python.org/archives/list/python-dev@python.org/thread/MPHZ3TGSHMSF7C4P7JEP2ZCYLRA3ERC5/

https://github.com/python/cpython/pull/30851

I'll note that the whole idea of pyconfig*.h as installed header is problematic.
The thing is, various packages that use autoconf will have various similar macros in their own config.h and when they also include pyconfig*.h, that can cause a lot of issues.
You should look what e.g. libstdc++ does; it uses autoconf, but the autoconf generated header is then adjusted using sed, so that all the autoconf emitted
macros are in a namespace specific to the library:
/usr/include/c++/*/*/bits/c++config.h
It would be best if python did the same, picked some prefix and used that consistently.

The issue is going to be fixed upstream: https://bugs.python.org/issue46513

I don't see the need to track this issue downstream in Fedora, so I close the issue.

My assumption was that this blocks the reporter, as it was opened with "Severity: urgent", and we need to backport the fix as soon as available.

Miro:
> My assumption was that this blocks the reporter, as it was opened with "Severity: urgent", and we need to backport the fix as soon as available.

Oh sorry, I didn't notice. It makes sense to keep this issue open in this case ;-)

PR: https://src.fedoraproject.org/rpms/python3.10/pull-request/95

FEDORA-2022-077731e655 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-077731e655

FEDORA-2022-077731e655 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.