Use of legacy C integer types

[markshannon]

We use the C type long a lot in the C API, which is problem because long varies in size across platforms in a way that is hard to deal with. A long might be 32bit or 64bit on a 64bit platform, which makes for lots of #ifdefs and conditional logic that wouldn't be needed if we used C99 stdint integer types.

Our code is also full of int where we mean int32_t. int is almost always 32 bit, but it is not guaranteed.

[vstinner]

There was a similar annoying legacy issue with the usage of "int" for a length in Python 2. A very slow transition to Py_ssize_t took years to be completed. It was about PyArg_Parse and Py_Build API families. The migration was implemented by defining an opt-in macro in ported C extensions.

[steve-s]

Regarding Py_ssize_t or even ssize_t is that still good for ABI? My thinking is that in an ideal ABI one would only have types that have guaranteed exact size across systems and compilers (or at least across compilers on the same system), which in theory size_t and ssize_t don't have to. Related HPy issue hpyproject/hpy#426

[markshannon]

In theory, Py_ssize_t and size_t are not well defined, but in practice they are the same as intptr_t and uintptr_t.
We should prefer the more modern types though.

I don't think we can make all values a fixed size. The return type of a length function will depend on the size of the address space.

[encukou]

Issue for proposed guidelines: capi-workgroup/api-evolution#10

[vstinner]

Issue for proposed guidelines: capi-workgroup/api-evolution#10

I close this issue, let's continue the discussion there.