Commit Graph

315 Commits

Author SHA1 Message Date
Jeremy Hylton
03657cfdb0 replace PyXXX_Length calls with PyXXX_Size calls 2000-07-12 13:05:33 +00:00
Tim Peters
dbd9ba6a6c Nuke all remaining occurrences of Py_PROTO and Py_FPROTO. 2000-07-09 03:09:57 +00:00
Jack Jansen
d50338fbd9 Added support for H (unsigned short) specifier in PyArg_ParseTuple and
Py_BuildValue.
2000-07-06 12:22:00 +00:00
Guido van Rossum
db67739d4f Jack Jansen, Mac patch:
Include limits.h if we have it.
2000-07-01 01:09:43 +00:00
Guido van Rossum
ffcc3813d8 Change copyright notice - 2nd try. 2000-06-30 23:58:06 +00:00
Guido van Rossum
fd71b9e9d4 Change copyright notice. 2000-06-30 23:50:40 +00:00
Guido van Rossum
5e08cb8e50 Vladimir Marangozov:
This patch fixes a problem on AIX with the signed int case code in
getargs.c, after Trent Mick's intervention about MIN/MAX overflow
checks. The AIX compiler/optimizer generates bogus code with the
default flags "-g -O" causing test_builtin to fail: int("10", 16) <>
16L. Swapping the two checks in the signed int code makes the problem
go away.

Also, make the error messages fit in 80 char lines in the
source.
2000-06-28 23:53:56 +00:00
Fred Drake
230cae7474 Trent Mick <trentm@activestate.com>:
Limit the 'b' formatter of PyArg_ParseTuple to valid values of an unsigned
char, i.e. [0,UCHAR_MAX]. It is expected that this is the common usage of 'b'.
An OverflowError is raised if the parsed value is outside this range.
2000-05-09 21:50:00 +00:00
Guido van Rossum
80dc16baaa Trent Mick:
Changes the 'b', 'h', and 'i' formatters in PyArg_ParseTuple to raise an
Overflow exception if they overflow (previously they just silently
overflowed).

Changes by Guido: always accept values [0..255] (in addition to
[CHAR_MIN..CHAR_MAX]) for 'b' format; changed some spaces into tabs in
other code.
2000-05-08 14:02:41 +00:00
Fred Drake
25871c001f Brian Hooper <brian_takashi@hotmail.com>:
Added 'u' and 'u#' tags for PyArg_ParseTuple - these turn a
PyUnicodeObject argument into a Py_UNICODE * buffer, or a Py_UNICODE *
buffer plus a length with the '#'.  Also added an analog to 'U'
for Py_BuildValue.
2000-05-03 15:17:02 +00:00
Guido van Rossum
700c6ff1fb Marc-Andre Lemburg:
Fixed a memory leak found by Fredrik Lundh.  Instead of
PyUnicode_AsUTF8String() we now use _PyUnicode_AsUTF8String() which
returns the string object without incremented refcount (and assures
that the so obtained object remains alive until the Unicode object is
garbage collected).
2000-04-27 20:13:18 +00:00
Guido van Rossum
24bdb0474f Marc-Andre Lemburg:
The attached patch set includes a workaround to get Python with
Unicode compile on BSDI 4.x (courtesy Thomas Wouters; the cause
is a bug in the BSDI wchar.h header file) and Python interfaces
for the MBCS codec donated by Mark Hammond.

Also included are some minor corrections w/r to the docs of
the new "es" and "es#" parser markers (use PyMem_Free() instead
of free(); thanks to Mark Hammond for finding these).

The unicodedata tests are now in a separate file
(test_unicodedata.py) to avoid problems if the module cannot
be found.
2000-03-28 20:29:59 +00:00
Guido van Rossum
50fbb15b16 Typo fixed by Mark Hammond. 2000-03-28 02:00:29 +00:00
Guido van Rossum
d8855fde88 Marc-Andre Lemburg:
Attached you find the latest update of the Unicode implementation.
The patch is against the current CVS version.

It includes the fix I posted yesterday for the core dump problem
in codecs.c (was introduced by my previous patch set -- sorry),
adds more tests for the codecs and two new parser markers
"es" and "es#".
2000-03-24 22:14:19 +00:00
Guido van Rossum
e826ef0a89 Marc-Andre Lemburg: support for Unicode strings; 'U' expects a Unicode
object.
2000-03-10 23:02:17 +00:00
Guido van Rossum
66368ccc55 Patch by Tommy Burnette to accept an arbitrary sequence when "(...)"
is used in the format string, instead of requiring a tuple.  This is
in line with the general trend towards accepting arbitrary sequences.
1999-02-17 23:16:43 +00:00
Guido van Rossum
3dbba6ec3a Change rare occurrences of #if HAVE_LONG_LONG to #ifdef. 1999-01-25 21:48:56 +00:00
Guido van Rossum
b317f8aa0d Implement new format character 't#'. This is like s#, accepting an
object that implements the buffer interface, but requires a buffer
that contains 8-bit character data.  Greg Stein.
1998-10-08 02:21:21 +00:00
Guido van Rossum
3293b07df5 Patch by Mark Hammond to support 64-bit ints on MS platforms.
The MS compiler doesn't call it 'long long', it uses __int64,
so a new #define, LONG_LONG, has been added and all occurrences
of 'long long' are replaced with it.
1998-08-25 16:07:15 +00:00
Guido van Rossum
1a8791e0b8 Changes for BeOS, QNX and long long, by Chris Herborth. 1998-08-04 22:46:29 +00:00
Guido van Rossum
fccfe89753 Another veeeeeery old patch...
Date:    Thu, 14 Sep 1995 12:18:20 -0400
From:    Alan Morse <alan@dvcorp.com>
To:      python-list@cwi.nl
Subject: getargs bug in 1.2 and 1.3 BETA

We have found a bug in the part of the getargs code that we added
and submitted, and which was incorporated into 1.1.

The parsing of "O?" format specifiers is not handled correctly;
there is no "else" for the "if" and therefore it can never fail.
What's worse, the advancing of the varargs pointer is not
handled properly, so from then on it is out of sync, wreaking
all sorts of havoc. (If it had failed properly, then the out-of-sync
varargs would not have been an issue.)

Below is the context diff for the change.

Note that I have made a few stylistic changes beyond adding the
else case, namely:

1) Making the "O" case follow the convention established by the other
format specifiers of getting all their vararg arguments before
performing the test, rather than getting some before and some after
the test passes.

2) Making the logic of the tests parallel, so the "if" part indicates
that the format is accepted and the "else" part indicates that the
format has failed. They were inconsistent with each other and with the
the other format specifiers.

-Alan Morse (amorse@dvcorp.com)
1998-05-15 22:04:07 +00:00
Guido van Rossum
730806d3d9 Make new gcc -Wall happy 1998-04-10 22:27:42 +00:00
Guido van Rossum
0d6b49eff2 Protect PyErr_Format format string argument from overflow (ironically,
the error was about a bad format string :-).
1998-01-19 22:22:44 +00:00
Guido van Rossum
7d4f68c15f Oops -- '(' is also a legal start character of a new format... 1997-12-19 04:25:23 +00:00
Guido van Rossum
231a41e708 Add explicit check for correct next character in format at end of
format.  This will complain about illegal formats like "O#" instead of
ignoring the '#'.
1997-12-09 20:36:39 +00:00