[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: Thank you very much to the task force who worked on this issues which can be seen as boring and useless, but are very important nowadays with C compilers which are more and more agressive to optimize everything (I'm looking at you clang!). This bug is open

[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: New changeset 6665802549006eb50c1a68c3489ee3aaf81d0c8e by Victor Stinner (Miss Islington (bot)) in branch '3.7': bpo-1621: Avoid signed integer overflow in set_table_resize() (GH-9059) (GH-9198)

[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: New changeset a9274f7b3f69519f0746c50f85a68abd926ebe7b by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-1621: Avoid signed integer overflow in set_table_resize(). (GH-9059) (GH-9199)

[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: Benjamin: what do you think of adding an explicit check after the "new_size <<= 1;" loop? if (new_size > (size_t)PY_SSIZE_T_MAX) { PyErr_NoMemory(); return -1; } Technically, PyMem_Malloc() already implements the check, so it's not

[issue1621] Do not assume signed integer overflow behavior

Change by Benjamin Peterson : -- pull_requests: +8692, 8693 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

Change by Benjamin Peterson : -- pull_requests: +8692 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: I asked if there is an issue. In fact, all Python memory allocators start by checking if the size is larger than PY_SSIZE_T_MAX. Example: void * PyMem_RawMalloc(size_t size) { /* * Limit ourselves to PY_SSIZE_T_MAX bytes to prevent security holes.

[issue1621] Do not assume signed integer overflow behavior

Sergey Fedoseev added the comment: > Now you rely on PyMem_Malloc() to detect the overflow. Now overflow is not possible or am I missing something? -- nosy: +sir-sigurd ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Jeffrey Walton added the comment: On Tue, Sep 11, 2018 at 8:26 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> newsize <<= 1; // The largest possible value is PY_SSIZE_T_MAX + 1. > > Previously, there was a explicitly check for error raising PyErr_NoMemory() > on

[issue1621] Do not assume signed integer overflow behavior

STINNER Victor added the comment: > newsize <<= 1; // The largest possible value is PY_SSIZE_T_MAX + 1. Previously, there was a explicitly check for error raising PyErr_NoMemory() on overflow. Now you rely on PyMem_Malloc() to detect the overflow. I'm not sure that it's a good idea.

[issue1621] Do not assume signed integer overflow behavior

Change by miss-islington : -- pull_requests: +8633 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

Change by miss-islington : -- pull_requests: +8634 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

miss-islington added the comment: New changeset 6c7d67ce83a62b5f0fe5c53a6df602827451bf7f by Miss Islington (bot) (Sergey Fedoseev) in branch 'master': bpo-1621: Avoid signed integer overflow in set_table_resize(). (GH-9059)

[issue1621] Do not assume signed integer overflow behavior

Change by Sergey Fedoseev : -- pull_requests: +8519 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

Change by Gregory P. Smith : -- versions: +Python 3.7, Python 3.8 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Sorry I haven’t made a PR for ctypes_v2.patch, but I don’t mind if someone else takes over. I understand the HAVE_LONG_LONG check may no longer necessary for newer Python versions. -- ___

[issue1621] Do not assume signed integer overflow behavior

Serhiy Storchaka added the comment: Martin, do you mind to create a PR for your ctypes_v2.patch? -- ___ Python tracker ___

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot added the comment: New changeset dd2c7d497878 by Martin Panter in branch '3.5': Issues #1621, #29145: Test for str.join() overflow https://hg.python.org/cpython/rev/dd2c7d497878 New changeset eb6eafafdb44 by Martin Panter in branch 'default': Issue #1621: Overflow should not be

[issue1621] Do not assume signed integer overflow behavior

Changes by Martin Panter : -- dependencies: +failing overflow checks in replace_* ___ Python tracker ___

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: It's good Martin. Just commit it. -- ___ Python tracker ___ ___

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Xiang: regarding your overflow_fix_in_listextend.patch, what do you think about adding a comment or debugging assertion instead, something like: /* It should not be possible to allocate a list large enough to cause an overflow on any relevant platform */

[issue1621] Do not assume signed integer overflow behavior

Changes by Christian Heimes : -- nosy: -christian.heimes ___ Python tracker ___ ___

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: I agree. For multibytecode, how about switching the positions of the two checks? If npendings + ctx->pendingsize overflows, the result can be anything, larger, smaller than or equal to MAXDECPENDING. For ast, although a SystemError may be raised but the message

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Looking over r60793, the overflow check at Modules/cjkcodecs/multibytecodec.c:836 looks vulnerable to being optimized away, because it can only detect the overflow if the line above has already overflowed. Perhaps change PY_SSIZE_T_MAX to MAXDECPENDING. I

[issue1621] Do not assume signed integer overflow behavior

Antti Haapala added the comment: I don't believe Python would really ever work on a platform with non-8-bit-bytes, I believe there are way too much assumptions *everywhere*. You can program in C on such a platform, yes, but not that sure about Python. And on 8-bit-byte platfomrs, there is no

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: So these checks are superfluous? Do we need to remove them? Hmm, I still doubt such checks should consider platform characteristics first. In theory List can be PY_SSIZE_T_MAX length. Do we have to put the PY_SIZE_MAX // sizeof(PyObject *) limit on it?

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: The check in ins1() was originally added in revision b9002da46f69. I presume it references the Python-dev thread “can this overflow (list insertion)?” <2812145155.a7...@activestate.com>, . At that time,

[issue1621] Do not assume signed integer overflow behavior

Changes by Gregory P. Smith : -- nosy: -gregory.p.smith ___ Python tracker ___ ___

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: Hmm, I don't tend to infer platform characteristics. IMHO, it's a simple problem: sum up two lists' length which may overflow in logic. With your argument, does it means it seems somewhat meaningless to have a List a Py_ssize_t length since it can never reach

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: overflow_fix_in_listextend.patch: I doubt Python supports the kinds of platform where this overflow would be possible. It may require pointers smaller than 32 bits, or char objects larger than 8 bits. Perhaps we could just add a comment explaining we assume

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: Martin, I upload a patch to fix another possible overflow in listextend. -- Added file: http://bugs.python.org/file43956/overflow_fix_in_listextend.patch ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot added the comment: New changeset db93af6080e7 by Martin Panter in branch 'default': Issue #1621: Avoid signed overflow in list and tuple operations https://hg.python.org/cpython/rev/db93af6080e7 -- ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: It turns out you just want to see the output. That is easy. Patch v3 adding the test. -- Added file: http://bugs.python.org/file43862/tuple_and_list_v3.patch ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: unicode.patch avoids an overflow in PyUnicode_Join(): >>> size = int(sys.maxsize**0.5) + 1 >>> "".join(("A" * size,) * size) Objects/unicodeobject.c:9927:12: runtime error: signed integer overflow: 46341 + 2147441940 cannot be represented in type 'int'

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Xiang: I don’t think we need to make the tests do anything special. Just make sure they exercise the code that handles overflows. I have been running the test suite without any -j0 option, and I can look over the output and see the error messages. Or if we get

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: It's cool, but I get one problem when writing tests. support.captured_stderr cannot capture the runtime error message. So we have nothing to do with the assertion and the test will always succeed even when overflow does happen (the message will be output). To

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: The error message comes from Undefined Behaviour Sanitizer, which was added to newer versions of GCC and Clang. Currently I am compiling with ./configure --with-pydebug CC="gcc -fsanitize=undefined -fno-sanitize=alignment -fno-sanitize=shift"

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: Change tuple_and_list.patch with empty curly braces. I don't add the test for __length_hint__. According to the comment, when overflow happens, it is either ignored or a MemoryError will finally be raised. I am not willing to test a MemoryError in this case.

[issue1621] Do not assume signed integer overflow behavior

Changes by Martin Panter : Added file: http://bugs.python.org/file43839/array-size.patch ___ Python tracker ___

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Perhaps we should add a test for the __length_hint__() overflow to tuple_and_list.patch: >>> a = [1,2,3,4] >>> import sys >>> class B: ... def __iter__(s): return s ... def __next__(s): raise StopIteration() ... def __length_hint__(s): return sys.maxsize ...

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Apart from the empty “if” statement style (see review), tuple_and_list.patch looks good to me. I understand the patches from 2011 and earlier have all been committed (correct me if I missed something). Here is another patch fixing a 64-bit overflow in

[issue1621] Do not assume signed integer overflow behavior

Xiang Zhang added the comment: @Martin, attach a patch to fix the overflow check you mentioned in tuple and list objects. -- nosy: +xiang.zhang Added file: http://bugs.python.org/file43827/tuple_and_list.patch ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Serhiy: slice-step.patch seems to be fine with negative slice steps. The actual indexes are still positive, and “unsigned” arithmetic is really modular arithmetic, so when you add the negative “unsigned” step value, it decrements the index properly. Antti: if

[issue1621] Do not assume signed integer overflow behavior

Antti Haapala added the comment: About shifts, according to C standard, right shifts >> of negative numbers are implementation-defined: "[in E1 >> E2], If E1 has a signed type and a negative value, the resulting value is implementation-defined." In K this meant that the number can be

[issue1621] Do not assume signed integer overflow behavior

Serhiy Storchaka added the comment: Does this work with negative steps? -- ___ Python tracker ___ ___

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: I committed the fix for negation in audioop. slice-step.patch includes a better fix for the remaining part of trapv.patch, with Element Tree slicing. I think this fix is much less intrusive, and I have copied it to other places that handle slicing, and added

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot added the comment: New changeset d6a86018ab33 by Martin Panter in branch 'default': Issue #1621: Avoid signed int negation overflow in audioop https://hg.python.org/cpython/rev/d6a86018ab33 -- ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Antti Haapala added the comment: Gnulib portability library has https://www.gnu.org/software/gnulib/manual/html_node/Integer-Range-Overflow.html and https://www.gnu.org/softwarhe/gnulib/manual/html_node/Integer-Type-Overflow.html and even macros for producing well-defined integer wraparound

[issue1621] Do not assume signed integer overflow behavior

Jeffrey Walton added the comment: > Has this sort of thing been done in other projects? Yes. If you are using C, you can use safe_iop. Android uses it for safer integer operations. If you are using C++, you can use David LeBlanc's SafeInt class. Microsoft uses it for safer inter operations.

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: I tried the newer -fsanitize=undefined mode, and it is better than -ftrapv. It adds instrumentation that by default nicely reports the errors and continues running. My problem with the large slice step is not restricted to Element Tree; it affects list

[issue1621] Do not assume signed integer overflow behavior

Serhiy Storchaka added the comment: The audioop part LGTM. If this case was found with the help of -ftrapv, I'm for adding this option in a debug build. -- nosy: +serhiy.storchaka ___ Python tracker

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: I added Issue 13312 as a dependency, there is currently a test for a negative year that relies on overflow handling. Here is a patch where I tried to fix overflow detection for huge set objects. -- Added file:

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Inspired by Issue 27473, I did a quick and dirty scan for obvious places that expect overflow to wrap, and found the following, which I think should be fixed: Modules/_ctypes/_ctypes.c:1388, in PyCArrayType_new() Objects/listobject.c:492, in list_concat()

[issue1621] Do not assume signed integer overflow behavior

Antti Haapala added the comment: One common case where signed integer overflow has been assumed has been the wraparound/overflow checks like in http://bugs.python.org/issue27473 I propose that such commonly erroneous tasks such as overflow checks be implemented as common macros in CPython as

[issue1621] Do not assume signed integer overflow behavior

Changes by Martin Panter : -- dependencies: +bytes_concat seems to check overflow using undefined behaviour ___ Python tracker ___

[issue1621] Do not assume signed integer overflow behavior

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Changes by Jakub Wilk jw...@jwilk.net: -- nosy: +jwilk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing list

[issue1621] Do not assume signed integer overflow behavior

Jeffrey Walton added the comment: Also see http://bugs.python.org/issue20944 for suggestions to identify the offending code. -- nosy: +Jeffrey.Walton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621

[issue1621] Do not assume signed integer overflow behavior

Changes by Florian Weimer fwei...@redhat.com: -- nosy: +fweimer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: See also issue #9530. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3fb9464f9b02 by Mark Dickinson in branch 'default': Issue #1621: Fix undefined behaviour from signed overflow in datetime module hashes, array and list iterations, and get_integer (stringlib/string_format.h)

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: Resetting versions. -- versions: +Python 3.3 -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: Clang has an -ftrapv option that seems to be less buggy and more complete than gcc's. Compiling and running the test suite with that option enabled looks like a good way to catch a lot of these signed overflows. --

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis mar...@v.loewis.de added the comment: Do we consider these overflows as bugs in Python, or do we declare that we expect compilers to do the right thing for the bug fix releases (i.e. care only about the default branch). I'd personally vote for the latter - i.e. don't apply any

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: don't apply any of the resulting changes to the maintenance releases, and target the issue only for 3.3. That sounds fine to me, though if we find more instances of signed overflow that actually trigger test failures in the maintenance

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 698fa089ce70 by Mark Dickinson in branch 'default': Issue #1621: Fix undefined behaviour in bytes.__hash__, str.__hash__, tuple.__hash__, frozenset.__hash__ and set indexing operations.

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 5e456e1a9e8c by Mark Dickinson in branch 'default': Issue #1621: Fix undefined behaviour from signed overflow in get_integer (stringlib/formatter.h) http://hg.python.org/cpython/rev/5e456e1a9e8c --

[issue1621] Do not assume signed integer overflow behavior

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing list

[issue1621] Do not assume signed integer overflow behavior

Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing

[issue1621] Do not assume signed integer overflow behavior

deadshort cploo...@gmail.com added the comment: Since this is still dribbling along I'll point out intobject.c:int_pow() and: prev = ix; /* Save value for overflow check */ if (iw 1) { ix = ix*temp; if (temp == 0) break; /*

[issue1621] Do not assume signed integer overflow behavior

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Changes by Dave Malcolm dmalc...@redhat.com: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 2.7, Python 3.2 -Python 2.5, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___

[issue1621] Do not assume signed integer overflow behavior

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis mar...@v.loewis.de added the comment: I'm finding many overflow checks that look like: size = Py_SIZE(a) * n; if (n size / n != Py_SIZE(a)) { PyErr_SetString(PyExc_OverflowError, repeated bytes are too long);

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis mar...@v.loewis.de added the comment: size = Py_SIZE(a) * n; The multiplication should be safe from overflow, and I don't get any warning at all either with this rewrite (using -O3 -Wall -Wextra - Wsigned-overflow=5) or from the original code, so there's nothing to

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis mar...@v.loewis.de added the comment: I don't see why. There's nothing in -Wall -Wextra -Wsigned-overflow that asks for warnings for code that might overflow. Ah, right. I misunderstood (rather, didn't bother checking) what -Wsigned-overflow really does. --

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: This is puzzling, isn't it? I don't see why. There's nothing in -Wall -Wextra -Wsigned-overflow that asks for warnings for code that might overflow. Indeed, I don't see how any compiler could reasonably provide such warnings without

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: Aargh! s/Wsigned-overflow/Wstrict-overflow/g Sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: A few comments: (1) I agree that signed overflows should be avoided where possible. (2) I think some of the changes in the latest patch (fix-overflows-final.patch) are unnecessary, and decrease readability a bit. An example is the following

[issue1621] Do not assume signed integer overflow behavior

Gregory P. Smith g...@krypto.org added the comment: I assume these changes were made to silence warnings from -Wstrict-overflow, but I don't think that should be a goal: I'd suggest only making changes where there's a genuine possibility of overflow (even if it's a remote one), and leaving the

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: There is a lot of value in being able to compile with -Wstrict-overflow and know that every warning omitted is something to be looked at. I agree in principle; this certainly applies to -Wall. But -Wstrict- overflow doesn't do a

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez ism...@namtrac.org added the comment: You should be using gcc 4.4 to get the best warning behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: Thanks Ismail. I'm currently using gcc-4.4 with the -ftrapv (not -fwrapv!) option to see how much breaks. (Answer: quite a lot. :-[ ) I'm finding many overflow checks that look like: size = Py_SIZE(a) * n; if (n size / n

[issue1621] Do not assume signed integer overflow behavior

Mark Dickinson dicki...@gmail.com added the comment: [and then perform the multiplication unsigned, to silence the warning - right?] That wasn't actually what I was thinking: I was proposing to rewrite it as: if (Py_SIZE(a) 0 n PY_SSIZE_T_MAX/Py_SIZE(a)) {

[issue1621] Do not assume signed integer overflow behavior

Changes by Daniel Diniz aja...@gmail.com: -- nosy: +haypo stage: - patch review versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___

[issue1621] Do not assume signed integer overflow behavior

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing

[issue1621] Do not assume signed integer overflow behavior

Changes by jan matejek [EMAIL PROTECTED]: -- nosy: +matejcik __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Any news on this? Also gcc 4.3 gcc 4.2.3 fixed the -Wall clobbering - Wstrict-overflow problem, which is good news. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __

[issue1621] Do not assume signed integer overflow behavior

Martin v. Löwis added the comment: With Neal, I don't see what the warning in _csv is about. What condition is being turned into a constant? Is the compiler perhaps rearranging the code so as to insert if (field[0] == '\0') goto XXX; in front of the for-loop where XXX jumps into the middle

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: I wonder if it would help making i a Py_ssize_t instead of an int? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __ ___

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Moving the empty check before the loop will fix this and possibly optimize empty string handling. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621 __

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Guido van Rossum added the comment: I wonder if it would help making i a Py_ssize_t instead of an int? gcc still issues the same warning with that. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Neal, You could btw check http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix which have each fix seperate so that reviewing is easy. Just ignore configure changes thats for later. Thanks, ismail __ Tracker [EMAIL

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: gcc is optimizing the second if check , for specifically i == 0 seems to redundant according to gcc. if (i == 0 quote_empty) { if (dialect-quoting == QUOTE_NONE) { PyErr_Format(error_obj,

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: Thanks for the through review! I will add -Wsign-compare and fix new warnings. Btw current state is with the patch -fwrapv is not needed and no regressions. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1621

[issue1621] Do not assume signed integer overflow behavior

Neal Norwitz added the comment: I just added -Wstrict-overflow to the code in sysmodule.c (sys_getframe) and tried with gcc 4.2.1. It doesn't warn. I wonder if 4.3 is more picky or warns when it shouldn't? Unless if I changed the code so it doesn't work: typedef struct {int ref;} PyObject;

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: Unfortunately I have no time to work on this myself, but in order to make progress I recommend checking in things piecemeal so that the same changes don't get reviewed over and over again. I propose that each submit reference this bug (Partial fix for issue

  1   2   >