| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.)
|
| |
|
|
|
| |
exception. The bug fix for SF #430849 wasn't quite right. This
closes SF bug #595671. I'll backport this to Python 2.2.
|
| |
|
|
|
|
| |
for Py_Main().
Thanks to Kalle Svensson and Skip Montanaro for the patches.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
memory, rather than the standard's 57.
This fixes SF bug #473009.
|
| |
|
|
| |
to make the SGI C compiler happier (bug #445960).
|
| |
|
|
| |
Decode and encode underscores for header style encoding. Fixes bug #463996.
|
| | |
|
| |
|
|
| |
#127718: '@' and '`' seem to be confused.
|
| |
|
|
| |
This should match the situation in the 1.6b1 tree.
|
| |
|
|
|
|
| |
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 ;)
|
| | |
|
| | |
|
| |
|
|
| |
PyArg_ParseTuple() format string arguments as possible.
|
| |
|
|
|
|
|
|
|
|
|
| |
(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.
|
| |
|
|
| |
_PyString_Resize() with a negative size.
|
| |
|
|
| |
on BeOS or Windows.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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/\'``!@
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
ascii input (thanks to Donald Beaudry for pointing these out)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
