Bugs item #1521947, was opened at 2006-07-13 17:39 Message generated for change (Comment added) made by nmm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-17 09:20 Message: Logged In: YES user_id=42444 Yes, this is a duplicate of 1521726. The compiler people's answer is correct, and mystrtoul.c is incorrect. LONG_MIN has been in C since C90, so should be safe, but its value may not always be what you expect. However, the code breakage is worse that just that test, and there are the following 3 cases of undefined behaviour: 1) Casting and unsigned long to long above LONG_MAX. 2) That test. 3) result = -result. The fix should be to make result unsigned long, and check the range BEFORE any conversion. Nothing else is safe. It is a matter of taste whether to include a fiddle for the number that can be held only when negated - I wouldn't, and would let that number be converted to a Python long, but others might disagree. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-17 01:13 Message: Logged In: YES user_id=33168 Is this a duplicate of 1521726? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
