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
errors raised by ctypes.Array for invalid _length_ attribute #74029
Comments
With regard to ctypes.Array: currently:
>>> from ctypes import *
>>> class T(Array):
... _type_ = c_int
... _length_ = -1
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: array too large
>>> class T(Array):
... _type_ = c_int
... _length_ = -1 << 1000
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: The '_length_' attribute is too large Obviously, here the _length_ attribute is too small, not too large. Moreover, in accordance with bpo-29833 (this is a sub-issue of bpo-29833), ValueError Also, Note that currently, in case _length_ == 0, no error is raised. ISTM that |
A patch draft (which doesn't change anything about the case of _length_ == 0) I ran the test module on my Windows 10, and it seems the patch doesn't break |
LGTM, but I prefer If use _testcapi the tests should be decorated with cpython_only. But I think that it is better to not use it. Limiting _length_ to C long (rather than size_t) is an implementation detail. The test with _length_ = 1 << 1000 should be enough. |
"If use _testcapi the tests should be decorated with cpython_only." at first, I thought so too, but then I searched for 'cpython_only' in so I assumed that test_ctypes itself is cpython_only. should test_structures.py be changed, then? |
I suggest just remove the test with LONG_MAX. |
yes, you are right, of course. but regardless of this issue, shouldn't test_structures.py be changed |
I'm working on this. Right now I'm searching other tests that use _testcapi without guards. |
Opened bpo-29845 for _testcapi issues. |
here is the patch updated according to your suggestions, Serhiy. however, I wonder about the case of a too large _length_. BTW, while inspecting code related to a too large _length_, I came across this
(in PyCArrayType_new):
if (length * itemsize < 0) {
PyErr_SetString(PyExc_OverflowError,
"array too large");
goto error;
}
I am not sure, but isn't this check unsafe? (e.g. if length == 2 ** 30, and
itemsize == 4, couldn't the product be 0 on some platforms?)
but maybe the code before this check makes more checks. I didn't make a
thorough inspection... |
Oren, won't the "too large _length_" case vanish, if #3006 would be accepted ? |
I am not sure I understood your question, Igor. I compiled with https://github.com/python/cpython/pull/3006, and got:
class T(ctypes.Array):
_type_ = ctypes.c_int
_length_ = 2 ** 1000
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t
and also:
class T(ctypes.Array):
_type_ = ctypes.c_int
_length_ = -1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: array too large |
Oren,
|
Should this be back-ported to 3.7 and 3.6? 2.7? |
IMHO it's a bad idea to introduce a *new* exception in stable version. I suggest to only modify the master branch. |
This change is big enough now. I think it is better to not backport it. |
Thanks for all of your work on this Oren! |
( #10029 has been merged, but GitHub webhooks are paused and so no notification has been sent to this bug yet. ) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: