fix a bug in the previous commit. don't leak empty list on error return and
fix the additional rare (out of memory only) bug that it was supposed to fix
of not freeing log_list when the python allocator failed.
bugfix: when log_archive was called with the DB_ARCH_REMOVE flag present
in BerkeleyDB >= 4.2 it tried to construct a list out of an uninitialized
char **log_list.
feature: export the DB_ARCH_REMOVE flag by name in the module on BerkeleyDB >= 4.2.
The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them. See python-dev discussion.
Note that a branch can (and should) be created for resolving these
problems, like
Tim Peters [Sun, 4 Jun 2006 03:38:04 +0000 (03:38 +0000)]
_PyObject_DebugMalloc(): The return value should add
2*sizeof(size_t) now, not 8. This probably accounts for
current disasters on the 64-bit buildbot slaves.
Tim Peters [Sun, 4 Jun 2006 03:26:02 +0000 (03:26 +0000)]
In a PYMALLOC_DEBUG build obmalloc adds extra debugging info
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.
Fredrik Lundh [Sat, 3 Jun 2006 21:56:05 +0000 (21:56 +0000)]
"_self" is a said to be a reserved word in Watcom C 10.6. I'm
not sure that's really standard compliant behaviour, but I guess
we have to fix that anyway...
Tim Peters [Fri, 2 Jun 2006 23:22:51 +0000 (23:22 +0000)]
pprint functions used to sort a dict (by key) if and only if
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.
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)
Tim Peters [Thu, 1 Jun 2006 15:50:44 +0000 (15:50 +0000)]
Armin committed his patch while I was reviewing it (I'm sure
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 [Thu, 1 Jun 2006 13:56:26 +0000 (13:56 +0000)]
Re-enable a new empty-string test added during the NFS sprint,
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.
Neal Norwitz [Thu, 1 Jun 2006 05:32:49 +0000 (05:32 +0000)]
Remove ; at end of macro. There was a compiler recently that warned
about extra semi-colons. It may have been the HP C compiler.
This file will trigger a bunch of those warnings now.
Tim Peters [Wed, 31 May 2006 15:33:22 +0000 (15:33 +0000)]
_range_error(): Speed and simplify (there's no real need for
loops here). Assert that size_t is actually big enough, and
that f->size is at least one. Wrap a long line.
[Bug #1473048]
SimpleXMLRPCServer and DocXMLRPCServer don't look at
the path of the HTTP request at all; you can POST or
GET from / or /RPC2 or /blahblahblah with the same results.
Security scanners that look for /cgi-bin/phf will therefore report
lots of vulnerabilities.
Fix: add a .rpc_paths attribute to the SimpleXMLRPCServer class,
and report a 404 error if the path isn't on the allowed list.
Possibly-controversial aspect of this change: the default makes only
'/' and '/RPC2' legal. Maybe this will break people's applications
(though I doubt it). We could just set the default to an empty tuple,
which would exactly match the current behaviour.
Fixup the PCBuild8 project directory. exceptions.c have moved to Objects, and the functionalmodule.c has been replaced with _functoolsmodule.c. Other minor changes to .vcproj files and .sln to fix compilation
Tim Peters [Tue, 30 May 2006 15:53:34 +0000 (15:53 +0000)]
PyLong_FromString(): Continued fraction analysis (explained in
a new comment) suggests there are almost certainly large input
integers in all non-binary input bases for which one Python digit
too few is initally allocated to hold the final result. Instead
of assert-failing when that happens, allocate more space. Alas,
I estimate it would take a few days to find a specific such case,
so this isn't backed up by a new test (not to mention that such
a case may take hours to run, since conversion time is quadratic
in the number of digits, and preliminary attempts suggested that
the smallest such inputs contain at least a million digits).
Neal Norwitz [Tue, 30 May 2006 07:36:54 +0000 (07:36 +0000)]
I'm impatient. I think this will fix a few more problems with the buildbots.
I'm not sure this is the best approach, but I can't think of anything better.
If this creates problems, feel free to revert, but I think it's safe and
should make things a little better.
Tim Peters [Tue, 30 May 2006 05:23:59 +0000 (05:23 +0000)]
dict_print(): So that Neal & I don't spend the rest of
our lives taking turns rewriting code that works ;-),
get rid of casting illusions by declaring a new variable
with the obvious type.