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/\'``!@
Tim Peters
Guido van Rossum
Greg Ward
Martin v. Löwis
Peter Schneider-Kamp
Barry Warsaw
Andrew M. Kuchling
Thomas Wouters
Roger E. Masse
Jack Jansen