Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of legacy C integer types #27

Closed
markshannon opened this issue May 14, 2023 · 5 comments
Closed

Use of legacy C integer types #27

markshannon opened this issue May 14, 2023 · 5 comments
Labels
evolution-proposed theme: implementation flaws problems with the implementation of specific APIs theme: the C language issues related to the way we use the C language

Comments

@markshannon
Copy link

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.

@iritkatriel iritkatriel added the theme: implementation flaws problems with the implementation of specific APIs label May 14, 2023
@vstinner
Copy link
Contributor

vstinner commented May 17, 2023

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
Copy link
Contributor

steve-s commented May 19, 2023

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
Copy link
Author

markshannon commented May 19, 2023

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.

@iritkatriel iritkatriel added the theme: the C language issues related to the way we use the C language label Jul 13, 2023
@iritkatriel iritkatriel added the v label Jul 21, 2023
@iritkatriel iritkatriel removed the v label Oct 23, 2023
@encukou
Copy link
Contributor

encukou commented Oct 23, 2023

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

@vstinner
Copy link
Contributor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
evolution-proposed theme: implementation flaws problems with the implementation of specific APIs theme: the C language issues related to the way we use the C language
Projects
None yet
Development

No branches or pull requests

5 participants