Skip to content

Unify the definition of PyVarObject by using PyObject_HEAD - #31842

Closed
Tric333 wants to merge 1 commit into
python:mainfrom
Tric333:main
Closed

Tric333 wants to merge 1 commit into
python:mainfrom
Tric333:main

Conversation

@Tric333

@Tric333 Tric333 commented Mar 13, 2022

Copy link
Copy Markdown

No description provided.

@the-knights-who-say-ni

Copy link
Copy Markdown

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@Tric333

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@ronaldoussoren

Copy link
Copy Markdown
Contributor

I don't think this change is correct due to the C standard. In particular, CPython uses "PyObject*" to represent pointers to values. This is correct (according to aliasing rules) when the pointed-to value is either a PyObject struct, or a struct where the first field is a PyObject value.

PyVarObject is currently a struct with a PyObject value as the first field (second case), which means a "PyVarObject*" can be safely casted to "PyObject*". With your change this is no longer valid according C's aliasing rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

interpreter-core (Objects, Python, Grammar, and Parser dirs)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants