Skip to content

bpo-28129: fix ctypes crashes #386

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

Merged
merged 6 commits into from
Mar 2, 2017

Conversation

orenmn
Copy link
Contributor

@orenmn orenmn commented Mar 1, 2017

bpo-28129:

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA. This is necessary for legal reasons before we can look at your contribution. Please follow these steps to help rectify the issue:

  1. If you don't have an account on b.p.o, please create one
  2. Make sure your GitHub username is listed in "Your Details" at b.p.o
  3. If you have not already done so, please sign the PSF contributor agreement. The "bugs.python.org username " requested by the form is the "Login name" field under "Your Details".
  4. If you just signed the CLA, please wait at least one US business day and then check "Your Details" on bugs.python.org to see if your account has been marked as having signed the CLA (the delay is due to a person having to manually check your signed CLA)
  5. Reply here saying you have completed the above steps

Thanks again to your contribution and we look forward to looking at it!

@orenmn
Copy link
Contributor Author

orenmn commented Mar 2, 2017 via email

assert(CDataObject_Check(inst));
if (!CDataObject_Check(inst)) {
PyErr_SetString(PyExc_TypeError,
"not a ctype instance");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ctypes with a S no?

assert(CDataObject_Check(inst));
if (!CDataObject_Check(inst)) {
PyErr_SetString(PyExc_TypeError,
"not a ctype instance");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ctypes with a S no?

@vstinner
Copy link
Member

vstinner commented Mar 2, 2017

"I signed the CLA half a year ago, but only now added my GitHub username to my details at bpo."

Fixed. I removed the red "CLA not signed" label, and the bug added the green "CLA signed" label.

@orenmn
Copy link
Contributor Author

orenmn commented Mar 2, 2017

replaced 'ctype' with 'ctypes' in my patches, and also in an error message in Modules/_ctypes/_ctypes.c
(which is the one I originally copied while writing my patch).
thanks, haypo.

@vstinner
Copy link
Member

vstinner commented Mar 2, 2017

replaced 'ctype' with 'ctypes' in my patches, and also in an error message in Modules/_ctypes/_ctypes.c (which is the one I originally copied while writing my patch).

I'm sorry, it seems like "ctype" is the correct name. I found it in other parts of the code, but not in the doc. Please remove or revert the new change.

@orenmn
Copy link
Contributor Author

orenmn commented Mar 2, 2017

in https://docs.python.org/3.7/library/ctypes.html, the term 'ctypes instance' is used 9 times, while
the word 'ctype' isn't used at all.
also, the terms 'ctypes instance' and 'ctypes type' can be found in some places in
Modules_ctypes (among others, in error messages).

what code persuaded you "ctype" is the correct name?

I searched for ctype as a whole word in all *.c, *.h, *.py files, and most of what I found was
stuff that used ctype as a short for 'character type' or 'content type'.
I found only a few places that use 'ctype' while talking about ctypes stuff (most of them in
Modules/_ctypes/_ctypes.c).
I also found one such place in my patch, so in case we go with ctypes, I should change it
before you merge the pull request :)

@vstinner
Copy link
Member

vstinner commented Mar 2, 2017 via email

@vstinner vstinner merged commit 1bea762 into python:master Mar 2, 2017
@tiran
Copy link
Member

tiran commented Mar 2, 2017

Coverity found three potential NULL deref. One is a false positive, the remaining two are handled in #403.

vstinner added a commit that referenced this pull request Sep 28, 2017
* init commit, with initial tests for from_param and fields __set__ and __get__, and some additions to from_buffer and from_buffer_copy

* added the rest of tests and patches. probably only a first draft.

* removed trailing spaces

* replace ctype with ctypes in error messages

* change back from ctypes instance to ctype instance

(cherry picked from commit 1bea762)
vstinner added a commit that referenced this pull request Sep 28, 2017
* init commit, with initial tests for from_param and fields __set__ and __get__, and some additions to from_buffer and from_buffer_copy

* added the rest of tests and patches. probably only a first draft.

* removed trailing spaces

* replace ctype with ctypes in error messages

* change back from ctypes instance to ctype instance

(cherry picked from commit 1bea762)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants