1. 28 Apr, 2002 3 commits
  2. 27 Apr, 2002 2 commits
    • Tim Peters's avatar
      Repair widespread misuse of _PyString_Resize. Since it's clear people · 5de9842b
      Tim Peters authored
      don't understand how this function works, also beefed up the docs.  The
      most common usage error is of this form (often spread out across gotos):
      
      	if (_PyString_Resize(&s, n) < 0) {
      		Py_DECREF(s);
      		s = NULL;
      		goto outtahere;
      	}
      
      The error is that if _PyString_Resize runs out of memory, it automatically
      decrefs the input string object s (which also deallocates it, since its
      refcount must be 1 upon entry), and sets s to NULL.  So if the "if"
      branch ever triggers, it's an error to call Py_DECREF(s):  s is already
      NULL!  A correct way to write the above is the simpler (and intended)
      
      	if (_PyString_Resize(&s, n) < 0)
      		goto outtahere;
      
      Bugfix candidate.
      5de9842b
    • Tim Peters's avatar
      SF patch 549375: Compromise PyUnicode_EncodeUTF8 · 602f740b
      Tim Peters authored
      This implements ideas from Marc-Andre, Martin, Guido and me on Python-Dev.
      
      "Short" Unicode strings are encoded into a "big enough" stack buffer,
      then exactly as much string space as they turn out to need is allocated
      at the end.  This should have speed benefits akin to Martin's "measure
      once, allocate once" strategy, but without needing a distinct measuring
      pass.
      
      "Long" Unicode strings allocate as much heap space as they could possibly
      need (4 x # Unicode chars), and do a realloc at the end to return the
      untouched excess.  Since the overallocation is likely to be substantial,
      this shouldn't burden the platform realloc with unusably small excess
      blocks.
      
      Also simplified uses of the PyString_xyz functions.  Also added a release-
      build check that 4*size doesn't overflow a C int.  Sooner or later, that's
      going to happen.
      602f740b
  3. 26 Apr, 2002 11 commits
  4. 25 Apr, 2002 9 commits
  5. 24 Apr, 2002 3 commits
  6. 23 Apr, 2002 12 commits
    • Tim Peters's avatar
      1e33ffa5
    • Tim Peters's avatar
      test_mmap started breaking on Windows, only when run after test_bsddb. · e12cda98
      Tim Peters authored
      On Win2K it thought 'foo' started at byte offset 0 instead of at the
      pagesize, and on Win98 it thought 'foo' didn't exist at all.  Somehow
      or other this is related to the new "in memory file" gimmicks in
      bsddb, but the old bsddb we use on Windows sucks so bad anyway I don't
      want to bother digging deeper.  Flushing the file in test_mmap after
      writing to it makes the problem go away, so good enough.
      e12cda98
    • Barry Warsaw's avatar
      Unit tests for the changes in abstract.c version 2.101. The debug · 906569de
      Barry Warsaw authored
      build's "undetected error" problems were originally detected with
      extension types, but we can whitebox test the same situations with
      new-style classes.
      906569de
    • Jack Jansen's avatar
      Regenerated. · 033b79c4
      Jack Jansen authored
      033b79c4
    • Barry Warsaw's avatar
      abstract_get_bases(): Clarify exactly what the return values and · f16951cf
      Barry Warsaw authored
      states can be for this function, and ensure that only AttributeErrors
      are masked.  Any other exception raised via the equivalent of
      getattr(cls, '__bases__') should be propagated up.
      
      abstract_issubclass(): If abstract_get_bases() returns NULL, we must
      call PyErr_Occurred() to see if an exception is being propagated, and
      return -1 or 0 as appropriate.  This is the specific fix for a problem
      whereby if getattr(derived, '__bases__') raised an exception, an
      "undetected error" would occur (under a debug build).  This nasty
      situation was uncovered when writing a security proxy extension type
      for the Zope3 project, where the security proxy raised a Forbidden
      exception on getattr of __bases__.
      
      PyObject_IsInstance(), PyObject_IsSubclass(): After both calls to
      abstract_get_bases(), where we're setting the TypeError if the return
      value is NULL, we must first check to see if an exception occurred,
      and /not/ mask an existing exception.
      
      Neil Schemenauer should double check that these changes don't break
      his ExtensionClass examples (there aren't any test cases for those
      examples and abstract_get_bases() was added by him in response to
      problems with ExtensionClass).  Neil, please add test cases if
      possible!
      
      I belive this is a bug fix candidate for Python 2.2.2.
      f16951cf
    • Jack Jansen's avatar
    • Barry Warsaw's avatar
      Rewrote the PyUnit description so that it now recommends to use · 5ca53747
      Barry Warsaw authored
      run_suite() instead of run_unittest().  Best practice is to plan for
      multiple test classes.
      5ca53747
    • Fred Drake's avatar
      Add text about circular references caused by storing frames in local · 99d17006
      Fred Drake authored
      variables.  This closes SF bug #543148.
      99d17006
    • Jack Jansen's avatar
      Second part of fix for #493826: regenerated suite modules so errn exists but... · 95df3fd1
      Jack Jansen authored
      Second part of fix for #493826: regenerated suite modules so errn exists but == 0 doesn't signal an error.
      
      Bugfix candidate.
      95df3fd1
    • Jack Jansen's avatar
      First part of fix for #493826: if 'errn' key exists in return value this... · 18983536
      Jack Jansen authored
      First part of fix for #493826: if 'errn' key exists in return value this doesn't necesarily signal an error, only if the value is non-zero it does. This
      does not correspond with my reading of the documentation, but the OSX Finder can return 'errn'=0, and it knows better than me:-)
      
      Bugfix candidate.
      18983536
    • Jeremy Hylton's avatar
      Ignore SIGXFSZ. · 1b0bf9b7
      Jeremy Hylton authored
      The SIGXFSZ signal is sent when the maximum file size limit is
      exceeded (RLIMIT_FSIZE).  Apparently, it is also sent when the 2GB
      file limit is reached on platforms without large file support.
      
      The default action for SIGXFSZ is to terminate the process and dump
      core.  When it is ignored, the system call that caused the limit to be
      exceeded returns an error and sets errno to EFBIG.  Python
      always checks errno on I/O syscalls, so there is nothing to do with
      the signal.
      1b0bf9b7
    • Jeremy Hylton's avatar
      Add tests for the recent resource module change. · 74ce77f0
      Jeremy Hylton authored
      Also add a test that Python doesn't die with SIGXFSZ if it exceeds the
      file rlimit.  (Assuming this will also test the behavior when the 2GB
      limit is exceed on a platform that doesn't have large file support.)
      74ce77f0