gh-127295: ctypes: Switch field accessors to fixed-width integers (GH-127297)
This should be a pure refactoring, without user-visible behaviour changes.
Before this change, ctypes uses traditional native C types, usually identified
by [`struct` format characters][struct-chars] when a short (and
identifier-friendly) name is needed:
- `signed char` (`b`) / `unsigned char` (`B`)
- `short` (`h`) / `unsigned short` (`h`)
- `int` (`i`) / `unsigned int` (`i`)
- `long` (`l`) / `unsigned long` (`l`)
- `long long` (`q`) / `unsigned long long` (`q`)
These map to C99 fixed-width types, which this PR switches to: -
- `int8_t`/`uint8_t`
- `int16_t`/`uint16_t`
- `int32_t`/`uint32_t`
- `int64_t`/`uint64_t`
The C standard doesn't guarantee that the “traditional” types must map to the
fixints. But, [`ctypes` currently requires it][swapdefs], so the assumption won't
break anything.
By “map” I mean that the *size* of the types matches. The *alignment*
requirements might not. This needs to be kept in mind but is not an issue in
`ctypes` accessors, which [explicitly handle unaligned memory][memcpy] for the
integer types.
Note that there are 5 “traditional” C type sizes, but 4 fixed-width ones. Two of
the former are functionally identical to one another; which ones they are is
platform-specific (e.g. `int`==`long`==`int32_t`.) This means that one of the
[current][current-impls-1] [implementations][current-impls-2] is redundant on
any given platform.
The fixint types are parametrized by the number of bytes/bits, and one bit for
signedness. This makes it easier to autogenerate code for them or to write
generic macros (though generic API like
[`PyLong_AsNativeBytes`][PyLong_AsNativeBytes] is problematic for performance
reasons -- especially compared to a `memcpy` with compile-time-constant size).
When one has a *different* integer type, determining the corresponding fixint
means a `sizeof` and signedness check. This is easier and more robust than the
current implementations (see [`wchar_t`][sizeof-wchar_t] or
[`_Bool`][sizeof-bool]).