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 *.
Several functions adopted the strategy of altering a full lengthed
string copy and resizing afterwards. That would fail if the initial
string was short enough (0 or 1) to be interned. Interning precluded
the subsequent resizing operation.
The solution was to make sure the initial string was at least two
characters long.
Added tests to verify that all binascii functions do not crater when
given an empty string argument.
This fixes the problem and the test passes. I'm not sure
the test is really correct though. It seems like it would
be better to raise an exception. I think that wasn't done
for backwards compatability.
Bugfix candidate.
binascii_a2b_qp() and binascii_b2a_qp() with calls to PyMem_Malloc() and
PyMem_Free(). These won't return NULL unless the allocations actually fail,
so it won't trigger a bogus memory error on some platforms <cough>AIX</cough>
when passed a length of zero.
invalid, rather than returning a string of random garbage of the
estimated result length. Closes SF patch #703471 by Hye-Shik Chang.
Will backport to 2.2-maint (consider it done.)
binascii_crc32(): The previous patch forced this to return the same
result across platforms. This patch deals with that, on a 64-bit box,
the *entry* value may have "unexpected" bits in the high four bytes.
Bugfix candidate.
binascii_crc32(): Make this return a signed 4-byte result across
platforms. The other way to make this platform-independent would be to
make it return an unsigned unbounded int, but the evidence suggests
other code out there treats it like a signed 4-byte int (e.g., existing
code writing the result with struct.pack "l" format).
Bugfix candidate.
binascii_b2a_base64(): We didn't allocate enough buffer space for very
short inputs (e.g., a 1-byte input can produce a 5-byte output, but we
only allocated 2 bytes). I expect that malloc overheads absorbed the
overrun in practice, but computing a correct upper bound is a very simple
change.
in binascii.c (only on platforms with signed chars -- although Py_CHARMASK
is documented as returning an int, it only does so on platforms with
signed chars).
commonly used functions to convert an arbitrary binary string into
a hexadecimal digit representation and back again. These are often
(and often differently) implemented in Python. Best to have one
common fast implementation. Specifically,
binascii_hexlify(): a.k.a. b2a_hex() to return the hex representation
of binary data.
binascii_unhexlify(): a.k.a. a2b_hex() to do the inverse conversion
(hex digits to binary data). The argument must have an even length,
and must contain only hex digits, otherwise a TypeError is raised.
and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.
All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:
long
func(a, b)
long a;
long b; /* flagword */
{
and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)
(e.g. used for ZIP files).
The patch includes code that says:
+ Copyright (C) 1986 Gary S. Brown. You may use this program, or
+ code or tables extracted from it, as desired without restriction.
My interpretation (and Jim's) is that Gary S Brown has no claims under
copyright, patent or other rights or interests. Lawyers might disagree.
reformatted.)
- Illegal padding is now ignored. (Recommendation by GvR.)
- Padding no longer removes characters from data string (resulting in
lost data/strings with negative lengths).
- Illegal characters outside the ASCII range are now ignored, instead
of possibly being remapped to a valid character.
Not sure why this is generated, but this fixes a problem with a
particular file that was received with the following final line:
F-WE<-*A5]AY]%7>8'&!!(_Y<F*55_"*%46"<OFG=>_5(F/\'``!@
Neal Norwitz
Jeremy Hylton
Raymond Hettinger
Martin v. Löwis
Barry Warsaw
Thomas Wouters
Mark Hammond
Tim Peters
Guido van Rossum
Greg Ward
Peter Schneider-Kamp
Andrew M. Kuchling
Roger E. Masse
Jack Jansen