PEP 7: Reword & split the "C dialect" section (GH-4557)

The motivation here is to avoid users reading PEP 7 as guarantees about
what compilers/settings are required to build Python or extensions.

I've also clarified a few things in line with current practice.


---------

Co-authored-by: Adam Turner <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>

Author: 3 people

peps/pep-0007.rst

@@ -26,12 +26,24 @@ particular rule:
    clean up someone else's mess (in true XP style).
 
 
-C dialect
-=========
+.. _c_dialect:
+
+C standards
+===========
+
+Follow the following standards.
+For features that aren't in the relevant standard, use CPython-specific
+wrappers (for example: ``_Py_atomic_store_int32``, ``Py_ALWAYS_INLINE``,
+``Py_ARITHMETIC_RIGHT_SHIFT``; ``_Py_ALIGNED_DEF`` in public headers).
+When adding such wrappers, try to make them easy to adjust for unsupported
+compilers.
 
 * Python 3.11 and newer versions use C11 without `optional features
-  <https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features>`_.
-  The public C API should be compatible with C++.
+  <https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features>`__.
+  The public C API should be compatible with C99 and C++.
+
+  (As a reminder to any users reading this: this PEP is a *style guide*; these
+  rules are there to be broken.)
 
 * Python 3.6 to 3.10 use C89 with several select C99 features:
 
@@ -44,15 +56,19 @@ C dialect
   - C++-style line comments
 
 * Python versions before 3.6 used ANSI/ISO standard C (the 1989 version
-  of the standard).  This meant (amongst many other things) that all
-  declarations must be at the top of a block (not necessarily at the
-  top of function).
+  of the standard).  This meant, amongst many other things, that all
+  declarations were at the top of a block.
+
+
+Common C code conventions
+=========================
 
-* Don't use compiler-specific extensions, such as those of GCC or MSVC
-  (e.g. don't write multi-line strings without trailing backslashes).
+* Don't use compiler-specific extensions, such as those of GCC or MSVC.
+  For example, don't write multi-line strings without trailing backslashes.
 
-* All function declarations and definitions must use full prototypes
-  (i.e. specify the types of all arguments).
+* All function declarations and definitions must use full prototypes.
+  That is, specify the types of all arguments and use ``(void)`` to declare
+  functions with no arguments.
 
 * No compiler warnings with major compilers (gcc, VC++, a few others).