exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.

Reviewed by Amaury Forgeot d'Arc.

 * crashes on memory allocation failure found with failmalloc
 * memory leaks found with valgrind
 * compiler warnings in opt mode which would lead to invalid memory reads
 * problem using wrong name in decimal module reported by pychecker

Update the valgrind suppressions file with new leaks that are small/one-time
leaks we don't care about (ie, they are too hard to fix).

TBR=barry
TESTED=./python -E -tt ./Lib/test/regrtest.py -uall (both debug and opt modes)
  in opt mode:
  valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
    ./python -E -tt ./Lib/test/regrtest.py -uall,-bsddb,-compiler \
                        -x test_logging test_ssl test_multiprocessing
  valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
    ./python -E -tt ./Lib/test/regrtest.py test_multiprocessing
  for i in `seq 1 4000` ; do
    LD_PRELOAD=~/local/lib/libfailmalloc.so FAILMALLOC_INTERVAL=$i \
        ./python -c pass
  done

At least some of these fixes should probably be backported to 2.5.

by denying s# to parse objects that have a releasebuffer procedure,
and introducing s*.

More module might need to get converted to use s*.

 http://mail.python.org/pipermail/python-dev/2008-June/079988.html

Python 2.6 should stick with PyString_* in its codebase.  The PyBytes_* names
in the spirit of 3.0 are available via a #define only.  See the email thread.

My tests don't show the promised speed up of 10%. The code is as fast as the old code for simple cases and slightly faster for complex cases with several of args and kwargs. But the patch simplifies the code, too.

The t# and w# formats were not correctly handled.

Will backport.

* unified the way intobject, longobject and mystrtoul handle
  values around -sys.maxint-1.

* in general, trying to entierely avoid overflows in any computation
  involving signed ints or longs is extremely involved.  Fixed a few
  simple cases where a compiler might be too clever (but that's all
  guesswork).

* more overflow checks against bad data in marshal.c.

* 2.5 specific: fixed a number of places that were still confusing int
  and Py_ssize_t.  Some of them could potentially have caused
  "real-world" breakage.

* list.pop(x): fixing overflow issues on x was messy.  I just reverted
  to PyArg_ParseTuple("n"), which does the right thing.  (An obscure
  test was trying to give a Decimal to list.pop()... doesn't make
  sense any more IMHO)

* trying to write a few tests...

C argument format strings; fixes rest of #1523610.

Also add a guard against NULL in converttuple and add a test case
(that previously would have crashed).

Actually, checking for INT_MAX and INT_MIN is correct since
the format code explicitly handles a C "int".

PyObject_CallMethod aware of PY_SSIZE_T_CLEAN.

passing a string.  Martin already fixed the actual crash by ensuring
Py_UNICODE is unsigned.  As discussed on python-dev, this fix
removes the possibility of creating a unicode string from a raw buffer.

There is an outstanding question of how to fix the crash in 2.4.

add a Py_SAFE_DOWNCAST() to make the code correct.

ultimately going to snprintf() not the python string formatter.  Right?

Most of these can be backported.

In C++, it's an error to pass a string literal to a char* function
without a const_cast().  Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.

I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc.  Predictably, there were a large set of functions that
needed to be fixed as a result of these changes.  The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].

One cast was required as a result of the changes:  A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.

evaluating keyword arguments.

(fixes bug #1119418)

commit a yelp about a noted flaw the error messages for METH_KEYWORDS
functions under some circumstances.

numbers in PyLong_AsLongLong, and update test suite accordingly.
Backported to 2.4.

Backported to 2.4.

[ 991812 ] PyArg_ParseTuple can miss errors with warnings as exceptions

as suggested in the report.

This is definitely a 2.3 candidate (as are most of the checkins I've
made in the last month...)

PyArg_VaParse().

Closes patch #550732.  Thanks Greg Chapman.