What makes these definitions better?

Do we need to support both C99 and pre-C99?

What is the minimum needed for CPython itself, or other libraries such as NumPy?

The oldest version of GCC I could find that we are using is 4.8.5 - https://github.com/python-pillow/docker-images/actions/runs/4813262439/jobs/8569570838#step:6:99

https://gcc.gnu.org/onlinedocs/gcc-4.8.5/cpp.pdf

The value 199409L signifies the 1989 C standard as amended in 1994, which is the current default; the value 199901L signifies the 1999 revision of the C standard. Support for the 1999 revision is not yet complete.

What is the minimum needed for CPython itself [...]?

PEP 7 says:

• Python 3.11 and newer versions use C11 without optional features. The public C API should be compatible with C++.
• Python 3.6 to 3.10 use C89 with several select C99 features:
  • Standard integer types in <stdint.h> and <inttypes.h>. We require the fixed width integer types.
  • static inline functions
  • designated initializers (especially nice for type declarations)
  • intermingled declarations
  • booleans
  • C++-style line comments

What is the minimum needed for [...] other libraries such as NumPy?

https://numpy.org/doc/stable/user/building.html says:

Much of NumPy is written in C. You will need a C compiler that complies with the C99 standard.

<stdint.h> is better because it's standardized, so we have a guarantee about what exists.

We previously discussed the minimum C version here: #6516
The oldest we found was GCC on CentOS 7 which uses gnu90 by default.

If we could guarantee that <stdint.h> exists we could simplify this file a lot, but it doesn't seem like we can do that yet.

Thanks. And CentOS 7 is EOL on 30 Jun 2024.

We could consider requiring a newer C for Pillow 10.4, due out the next day on 1 Jul 2024, but I'd be more comfortable rolling it into the next quarterly release seeing as it's a major bump (11.0, 15 Oct 2024, supporting Python 3.9+).

And we may want to keep support for older C versions longer, but let's re-evaluate in a year or so.

@nulano How does this look from the Windows perspective?

I don't see any Windows changes in this PR.
The long long fix looks like it would be Windows-specific, but it is in a non-Windows block, which is presumably why it hasn't been noticed until now.

If we could guarantee that <stdint.h> exists we could simplify this file a lot, but it doesn't seem like we can do that yet.

I think this also applies to Windows. I'm not sure if it is guaranteed to exist on Windows, but if it might not be present on other platforms, I see no reason to worry about it yet.