[Armin Rigo] >> There are more cases of signed integer overflows in the CPython source >> code base... >> >> That's on a 64-bits machine: >> >> [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 >> abs(-sys.maxint-1) == -sys.maxint-1 >< >> Humpf! Looks like one person or two need to do a quick last-minute >> review of all places trying to deal with -sys.maxint-1, and replace them >> all with the "official" fix from Tim [SF 1545668]. [Anthony Baxter] > Ick. We're now less than 24 hours from the scheduled release date for 2.5 > final. There seems to be a couple of approaches here: > > 1. Someone (it won't be me, I'm flat out with work and paperwriting today) > reviews the code and fixes it > 2. We leave it for a 2.5.1. I'm expecting (based on the number of bugs found > and fixed during the release cycle) that we'll probably need a 2.5.1 in about > 3 months. > 3. We delay the release until it's fixed. > > I'm strongly leaning towards (2) at this point. (1) would probably require > another release candidate, while (3) would result in another release > candidate and massive amount of sobbing from a lot of people (including me). I ignored this since I don't have a box where problems are visible (& nobody responded to my request to check my last flying-blind "fix" on a box where it mattered). Given that these are weird, unlikely-in-real-life endcase bugs specific to a single compiler, #2 is the natural choice. BTW, did anyone try compiling Python with -fwrapv on a box where it matters? I doubt that Python's speed is affected one way or the other, and if adding wrapv makes the problems go away, that would be an easy last-second workaround for all possible such problems (which of course could get fixed "for real" for 2.5.1, provided someone cares enough to dig into it).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4