as "a bug" because there's no other way in core Python to ensure that
bytes written are actually on disk. At least ZODB wants this guarantee,
for robustness against crashes.
of classic classes now. Alas, new-style classes are still a problem, and
didn't need to be fixed in 2.3 (they were already immune in 2.3 due to the
new-in-2.3 tp_del slot).
The move_finalizers() routine checks each object in the unreachable
list to see if it has a finalizer. If it does, it is moved to the
finalizers list. The collector checks by calling, effectively,
hasattr(obj, "__del__"). The hasattr() call can result in an
arbitrary amount of Python code being run, because it will invoke
getattr hooks on obj.
If a getattr() hook is run from move_finalizers(), it may end up
resurrecting or deallocating objects in the unreachable list. In
fact, it's possible that the hook causes the next object in the list
to be deallocated. That is, the object pointed to by gc->gc.gc_next
may be freed before has_finalizer() returns.
The problem with the previous revision is that it followed
gc->gc.gc_next before calling has_finalizer(). If has_finalizer()
gc->happened to deallocate the object FROM_GC(gc->gc.gc_next), then
the next time through the loop gc would point to freed memory. The
fix is to always follow the next pointer after calling
has_finalizer().
Note that Python 2.3 does not have this problem, because
has_finalizer() checks the tp_del slot and never runs Python code.
Tim, Barry, and I peed away the better part of two days tracking this
down.
Check for readline 2.2 features. This should make it possible to
compile readline.c again with GNU readline versions 2.0 or 2.1; this
ability was removed in readline.c rev. 2.49. Apparently the older
versions are still in widespread deployment on older Solaris
installations. With an older readline, completion behavior is subtly
different (a space is always added).
pack_float, pack_double, save_float: All the routines for creating
IEEE-format packed representations of floats and doubles simply ignored
that rounding can (in rare cases) propagate out of a long string of
1 bits. At worst, the end-off carry can (by mistake) interfere with
the exponent value, and then unpacking yields a result wrong by a factor
of 2. In less severe cases, it can end up losing more low-order bits
than intended, or fail to catch overflow *caused* by rounding.
invalid, rather than returning a string of random garbage of the
estimated result length. Closes SF patch #703471 by Hye-Shik Chang.
Backport from 2.3.
