- 04 Jun, 2006 2 commits
-
-
Tim Peters authored
to each allocated block. This was using 4 bytes for each such piece of info regardless of platform. This didn't really matter before (proof: no bug reports, and the debug-build obmalloc would have assert-failed if it was ever asked for a chunk of memory >= 2**32 bytes), since container indices were plain ints. But after the Py_ssize_t changes, it's at least theoretically possible to allocate a list or string whose guts exceed 2**32 bytes, and the PYMALLOC_DEBUG routines would fail then (having only 4 bytes to record the originally requested size). Now we use sizeof(size_t) bytes for each of a PYMALLOC_DEBUG build's extra debugging fields. This won't make any difference on 32-bit boxes, but will add 16 bytes to each allocation in a debug build on a 64-bit box.
-
Tim Peters authored
-
- 03 Jun, 2006 22 commits
-
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Fredrik Lundh authored
not sure that's really standard compliant behaviour, but I guess we have to fix that anyway...
-
Andrew M. Kuchling authored
Fix by renaming the variable. In a different module, Neal fixed it by renaming _self to self. There's already a variable named 'self' here, so I used selfptr. (I'm committing this on a Mac without Tk, but it's a simple search-and-replace. <crosses fingers>, so I'll watch the buildbots and see what happens.)
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Andrew M. Kuchling authored
-
Martin v. Löwis authored
-
Martin v. Löwis authored
-
- 02 Jun, 2006 6 commits
-
-
Tim Peters authored
the output required more than one line. "Small" dicts got displayed in seemingly random order (the hash-induced order produced by dict.__repr__). None of this was documented. Now pprint functions always sort dicts by key, and the docs promise it. This was proposed and agreed to during the PyCon 2006 core sprint -- I just didn't have time for it before now.
-
Martin Blais authored
-
Neal Norwitz authored
Prevent an invalid memory read from test_coding in case the done flag is set. In that case, the loop isn't entered. I wonder if rather than setting the done flag in the cases before the loop, if they should just exit early. This code looks like it should be refactored. Backport candidate (also the early break above if decoding_fgets fails)
-
Neal Norwitz authored
-
Neal Norwitz authored
-
Neal Norwitz authored
-
- 01 Jun, 2006 10 commits
-
-
Tim Peters authored
he didn't know this), so merged in some changes I made during review. Nothing material apart from changing a new `mask` local from int to Py_ssize_t. Mostly this is repairing comments that were made incorrect, and adding new comments. Also a few minor code rewrites for clarity or helpful succinctness.
-
Tim Peters authored
but disabled then because str and unicode strings gave different results. The implementations were repaired later during the sprint, but the new test remained disabled.
-
Tim Peters authored
-
Tim Peters authored
-
Armin Rigo authored
[ 1456209 ] dictresize() vulnerability ( <- backport candidate ).
-
Georg Brandl authored
-
Georg Brandl authored
-
Georg Brandl authored
-
Georg Brandl authored
-
Neal Norwitz authored
about extra semi-colons. It may have been the HP C compiler. This file will trigger a bunch of those warnings now.
-