In main, cpython/pystate.h newly includes stdbool.h, providing a definition for `bool` that might be incompatible with other software.

See here: https://github.com/cmusphinx/sphinxbase/pull/90

Eric, is this necessary? Would an old-school `int` do?
Or should we say it's 2022 already and everyone needs to use stdbool.hfore bools?

Is it compatible with C++?

Yes, stdbool.h is essentially a backport of C++'s bool type to C.

On Mon, Feb 14, 2022 at 2:28 AM Petr Viktorin <report@bugs.python.org> wrote:
> Eric, is this necessary? Would an old-school `int` do?
> Or should we say it's 2022 already and everyone needs to use stdbool.hfore bools?

I started using ``bool`` (stdbool.h) when I saw it specified in PEP 7
(https://www.python.org/dev/peps/pep-0007/#c-dialect).  If it is a
problem then I think it should be answered relative to PEP 7.  I'm not
sure what the best route is though.  Personally, I'd argue that if
it's in C99 then it should probably be standard at this point. :)
However, I'm not opposed to going back to plain int.  (And I know
there are definitely a number of old-school folks who prefer plain
int. :) )

It is in C99, but in an optional header.
IMO, including the header in the internals is perfectly OK, but opting everyone else in isn't very nice.
i.e. it would probably be OK to use `_Bool`, the actual C99 keyword that `bool` is defined as. But that's ugly enough to prefer `int`...

New changeset 2c228a7b8f89e9ed8d390370abd771d4993b79d8 by Petr Viktorin in branch 'main':
bpo-46748: Don't import <stdbool.h> in public headers (GH-31553)
https://github.com/python/cpython/commit/2c228a7b8f89e9ed8d390370abd771d4993b79d8

> New changeset 2c228a7b8f89e9ed8d390370abd771d4993b79d8 by Petr Viktorin in branch 'main':
> bpo-46748: Don't import <stdbool.h> in public headers (GH-31553)

It seems like this change broke ctypes on some architectures like s390x:

https://buildbot.python.org/all/#/builders/3/builds/1573

======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello_alias__]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: [] is not None
======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello__]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: ['/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/__phello__'] is not None
======================================================================
FAIL: test_frozentable (ctypes.test.test_values.PythonValuesTestCase) [__phello__.ham]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/ctypes/test/test_values.py", line 86, in test_frozentable
    self.assertIsNone(spec.submodule_search_locations)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: ['/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.clang/build/Lib/__phello__/ham'] is not None

New changeset e182c660b63bc23420fb9f0593d77a3fa3b7f1c7 by Kumar Aditya in branch 'main':
bpo-46748: Fix ctypes test_frozentable() (GH-31600)
https://github.com/python/cpython/commit/e182c660b63bc23420fb9f0593d77a3fa3b7f1c7

Can we close this?

Thank you, Kumar & Victor, for fixing up the issue!

I meant to check the buildbots before closing the issue, but got side-tracked.

> Thank you, Kumar & Victor, for fixing up the issue!

You're welcome. I'm happy to see that you reduced the number of #include in the C API ;-) I made similar changes in bpo-45434.