[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Tal Einat added the comment: New changeset 2447773573e74819e163f8963ab107bc5db123e5 by Tal Einat in branch 'master': bpo-29843: raise AttributeError if given negative _length_ (GH-10029) https://github.com/python/cpython/commit/2447773573e74819e163f8963ab107bc5db123e5 --

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

STINNER Victor added the comment: ( https://github.com/python/cpython/pull/10029 has been merged, but GitHub webhooks are paused and so no notification has been sent to this bug yet. ) -- ___ Python tracker

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Tal Einat added the comment: Thanks for all of your work on this Oren! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Serhiy Storchaka added the comment: This change is big enough now. I think it is better to not backport it. -- ___ Python tracker ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

STINNER Victor added the comment: > 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. -- nosy: +vstinner versions: +Python 3.8 -Python 3.7

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Change by Tal Einat : -- pull_requests: +9368 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Tal Einat added the comment: Should this be back-ported to 3.7 and 3.6? 2.7? -- nosy: +taleinat ___ Python tracker ___ ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Change by Oren Milman : -- pull_requests: +3807 ___ Python tracker ___ ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Change by Segev Finer : -- pull_requests: +3805 ___ Python tracker ___ ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Igor added the comment: Oren, 1) I might be completely wrong, but, personally, I think about OverflowError vs ValueError difference like this: if the value couldn't be handled because method's logic cannot handle it - it's a ValueError; if it could not be handled because of a low-level

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Oren Milman added the comment: 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 "", line

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Igor added the comment: Oren, won't the "too large _length_" case vanish, if https://github.com/python/cpython/pull/3006 would be accepted ? ( http://bugs.python.org/issue16865 ) -- nosy: +i3v ___ Python tracker

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Oren Milman added the comment: here is the patch updated according to your suggestions, Serhiy. however, I wonder about the case of a too large _length_. shouldn't we raise a MemoryError in such a case, in accordance with #29833? BTW, while inspecting code related to a too large _length_, I

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Serhiy Storchaka added the comment: Opened issue29845 for _testcapi issues. -- ___ Python tracker ___ ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Serhiy Storchaka added the comment: I'm working on this. Right now I'm searching other tests that use _testcapi without guards. -- ___ Python tracker

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Oren Milman added the comment: yes, you are right, of course. but regardless of this issue, shouldn't test_structures.py be changed (in a seperate issue)? ISTM it has a cpython-specific test not decorated in @cpython_only. -- ___ Python tracker

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Serhiy Storchaka added the comment: I suggest just remove the test with LONG_MAX. -- ___ Python tracker ___

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Oren Milman added the comment: "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 Lib/ctypes/test, and found nothing. then I searched for '_testcapi' there, and found a top level 'import _testcapi' in

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Serhiy Storchaka added the comment: LGTM, but I prefer `overflow > 0` over `overflow == 1`. 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

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

Oren Milman added the comment: A patch draft (which doesn't change anything about the case of _length_ == 0) is attached. (I am not opening a PR, because I am not sure the behavior change would be accepted.) I ran the test module on my Windows 10, and it seems the patch doesn't break anything.

[issue29843] errors raised by ctypes.Array for invalid _length_ attribute

New submission from Oren Milman: With regard to ctypes.Array: currently: >>> from ctypes import * >>> class T(Array): ... _type_ = c_int ... _length_ = -1 ... Traceback (most recent call last): File "", line 1, in OverflowError: array too large >>> class T(Array): ... _type_ =