summaryrefslogtreecommitdiffstats
path: root/Objects/intobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Port rev 55353 from Guido:Neal Norwitz2007-05-161-1/+1
| | | | | | | Add what looks like a necessary call to PyErr_NoMemory() when PyMem_MALLOC() fails. Will backport.
* As per Armin Rigo's suggestion, remove special handing from intobject.c to ↵Kristján Valur Jónsson2007-05-071-7/+2
| | | | deal with the peculiarities of classobject's implementation of the number protocol. The nb_long method of classobject now falls back to nb_int if there is no __long__ attribute present.
* Fix problems in x64 build that were discovered by the testsuite:Kristján Valur Jónsson2007-05-031-0/+4
| | | | | | | | | | | | - Reenable modules on x64 that had been disabled aeons ago for Itanium. - Cleared up confusion about compilers for 64 bit windows. There is only Itanium and x64. Added macros MS_WINI64 and MS_WINX64 for those rare cases where it matters, such as the disabling of modules above. - Set target platform (_WIN32_WINNT and WINVER) to 0x0501 (XP) for x64, and 0x0400 (NT 4.0) otherwise, which are the targeted minimum platforms. - Fixed thread_nt.h. The emulated InterlockedCompareExchange function didn´t work on x64, probaby due to the lack of a "volatile" specifier. Anyway, win95 is no longer a target platform. - Itertools module used wrong constant to check for overflow in count() - PyInt_AsSsize_t couldn't deal with attribute error when accessing the __long__ member. - PyLong_FromSsize_t() incorrectly specified that the operand were unsigned. With these changes, the x64 passes the testsuite, for those modules present.
* Variation of patch # 1624059 to speed up checking if an object is a subclassNeal Norwitz2007-02-251-1/+1
| | | | | | | | | | | | | | | | | | of some of the common builtin types. Use a bit in tp_flags for each common builtin type. Check the bit to determine if any instance is a subclass of these common types. The check avoids a function call and O(n) search of the base classes. The check is done in the various Py*_Check macros rather than calling PyType_IsSubtype(). All the bits are set in tp_flags when the type is declared in the Objects/*object.c files because PyType_Ready() is not called for all the types. Should PyType_Ready() be called for all types? If so and the change is made, the changes to the Objects/*object.c files can be reverted (remove setting the tp_flags). Objects/typeobject.c would also have to be modified to add conditions for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
* Minor change in int() docstring for proper spacing.Gustavo Niemeyer2007-01-101-1/+1
|
* Mention in the int() docstring that a base zero has meaning, asGustavo Niemeyer2007-01-101-2/+3
| | | | stated in http://docs.python.org/lib/built-in-funcs.html as well.
* Bug #1545497: when given an explicit base, int() did ignore NULsGeorg Brandl2006-10-121-2/+19
| | | | embedded in the string to convert.
* Forward-port of r52136,52138: a review of overflow-detecting code.Armin Rigo2006-10-041-2/+14
| | | | | | | | | | | | | | | | | | | | | | | * 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...
* Fix integer negation and absolute value to not relyMartin v. Löwis2006-10-041-4/+3
| | | | | on undefined behaviour of the C compiler anymore. Will backport to 2.5 and 2.4.
* "Conceptual" merge of rev 51711 from the 2.5 branch.Tim Peters2006-09-051-1/+1
| | | | | | | | | | | | i_divmod(): As discussed on Python-Dev, changed the overflow checking to live happily with recent gcc optimizations that assume signed integer arithmetic never overflows. This differs from the corresponding change on the 2.5 and 2.4 branches, using a less obscure approach, but one that /may/ tickle platform idiocies in their definitions of LONG_MIN. The 2.4 + 2.5 change avoided introducing a dependence on LONG_MIN, at the cost of substantially goofier code.
* Patch #1538606, Patch to fix __index__() clipping.Neal Norwitz2006-08-121-6/+11
| | | | | | | I modified this patch some by fixing style, some error checking, and adding XXX comments. This patch requires review and some changes are to be expected. I'm checking in now to get the greatest possible review and establish a baseline for moving forward. I don't want this to hold up release if possible.
* C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in ↵Skip Montanaro2006-04-181-17/+18
| | | | a couple places
* Fix int() and long() to repr() their argument when formatting the exception,Thomas Wouters2006-04-111-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to avoid confusing situations like: >>> int("") ValueError: invalid literal for int(): >>> int("2\n\n2") ValueError: invalid literal for int(): 2 2 Also report the base used, to avoid: ValueError: invalid literal for int(): 2 They now report: >>> int("") ValueError: invalid literal for int() with base 10: '' >>> int("2\n\n2") ValueError: invalid literal for int() with base 10: '2\n\n2' >>> int("2", 2) ValueError: invalid literal for int() with base 2: '2' (Reporting the base could be avoided when base is 10, which is the default, but hrm.) Another effect of these changes is that the errormessage can be longer; before, it was cut off at about 250 characters. Now, it can be up to four times as long, as the unrepr'ed string is cut off at 200 characters, instead. No tests were added or changed, since testing for exact errormsgs is (pardon the pun) somewhat errorprone, and I consider not testing the exact text preferable. The actually changed code is tested frequent enough in the test_builtin test as it is (120 runs for each of ints and longs.)
* More C++-compliance. Note especially listobject.c - to get C++ to accept theAnthony Baxter2006-04-111-6/+6
| | | | | | | | | PyTypeObject structures, I had to make prototypes for the functions, and move the structure definition ahead of the functions. I'd dearly like a better way to do this - to change this would make for a massive set of changes to the codebase. There's still some warnings - this is purely to get rid of errors first.
* Remove unnecessary casts in type object initializers.Georg Brandl2006-03-301-1/+1
|
* Checking in the code for PEP 357.Guido van Rossum2006-03-071-0/+1
| | | | | | This was mostly written by Travis Oliphant. I've inspected it all; Neal Norwitz and MvL have also looked at it (in an earlier incarnation).
* Use %ld and casts to long for refcount printing, in absense of a universallyThomas Wouters2006-03-011-2/+7
| | | | | available %zd format character. Mark with an XXX comment so we can fix this, later.
* Revert backwards-incompatible const changes.Martin v. Löwis2006-02-271-1/+1
|
* RFE #1436243: make integers in [0..256] preallocated.Georg Brandl2006-02-221-1/+1
|
* Avoid unused variables when SIZEOF_SIZE_T == SIZEOF_LONG. Also normalizeThomas Wouters2006-02-151-1/+3
| | | | whitespace.
* Merge ssize_t branch.Martin v. Löwis2006-02-151-1/+70
|
* Add const to several API functions that take char *.Jeremy Hylton2005-12-101-1/+1
| | | | | | | | | | | | | | | | | | | 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 *.
* Make subclasses of int, long, complex, float, and unicode perform typeBrett Cannon2005-04-261-1/+4
| | | | | | | conversion using the proper magic slot (e.g., __int__()). Also move conversion code out of PyNumber_*() functions in the C API into the nb_* function. Applied patch #1109424. Thanks Walter Doewald.
* Stop producing or using OverflowWarning. PEP 237 thought this wouldTim Peters2004-08-251-36/+4
| | | | | | | happen in 2.3, but nobody noticed it still was getting generated (the warning was disabled by default). OverflowWarning and PyExc_OverflowWarning should be removed for 2.5, and left notes all over saying so.
* Check the type of values returned by __int__, __float__, __long__,Neil Schemenauer2004-07-191-6/+0
| | | | | | __oct__, and __hex__. Raise TypeError if an invalid type is returned. Note that PyNumber_Int and PyNumber_Long can still return ints or longs. Fixes SF bug #966618.
* SF bug #980419: int left-shift causes memory leakRaymond Hettinger2004-06-261-4/+26
|
* Reword messageAndrew M. Kuchling2004-06-051-1/+1
|
* Fix exception wordingAndrew M. Kuchling2004-06-051-1/+1
|
* SF patch #875689: >100k alloc wasted on startupRaymond Hettinger2004-02-081-1/+1
| | | | | | | (Contributed by Mike Pall.) Make sure fill_free_list() is called only once rather than 106 times when pre-allocating small ints.
* - Removed FutureWarnings related to hex/oct literals and conversionsGuido van Rossum2003-11-291-30/+12
| | | | | | | | | | and left shifts. (Thanks to Kalle Svensson for SF patch 849227.) This addresses most of the remaining semantic changes promised by PEP 237, except for repr() of a long, which still shows the trailing 'L'. The PEP appears to promise warnings for operations that changed semantics compared to Python 2.3, but this is not implemented; we've suffered through enough warnings related to hex/oct literals and I think it's best to be silent now.
* Add a couple of decrefs to error paths.Michael W. Hudson2003-08-111-2/+4
| | | | | | | Now test_descr only appears to leak two references & I think this are in fact illusory (it's to do with things getting resurrected in __del__ methods & it's easy to be believe confusion occurs when that happens <wink>). Woohoo!
* SF patch 703666: Several objects don't decref tmp on failure in subtype_newRaymond Hettinger2003-06-281-1/+3
| | | | | | Submitted By: Christopher A. Craig Fillin some missing decrefs.
* SF # 595026: support for masks in getargs.c.Thomas Heller2003-04-171-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New functions: unsigned long PyInt_AsUnsignedLongMask(PyObject *); unsigned PY_LONG_LONG) PyInt_AsUnsignedLongLongMask(PyObject *); unsigned long PyLong_AsUnsignedLongMask(PyObject *); unsigned PY_LONG_LONG) PyLong_AsUnsignedLongLongMask(PyObject *); New and changed format codes: b unsigned char 0..UCHAR_MAX B unsigned char none ** h unsigned short 0..USHRT_MAX H unsigned short none ** i int INT_MIN..INT_MAX I * unsigned int 0..UINT_MAX l long LONG_MIN..LONG_MAX k * unsigned long none L long long LLONG_MIN..LLONG_MAX K * unsigned long long none Notes: * New format codes. ** Changed from previous "range-and-a-half" to "none"; the range-and-a-half checking wasn't particularly useful. New test test_getargs2.py, to verify all this.
* Strange control flow in PyInt_AsLong. When nb_int is called insideThomas Heller2003-02-201-3/+3
| | | | | | | | the PyInt_AsLong function, and this returns a long, the value is first retrieved with PyLong_AsLong, but afterwards overwritten by a call to PyInt_AS_LONG. Fixes SF #690253.
* Issue a warning when int('0...', 0) returns an int with the signGuido van Rossum2003-02-121-2/+12
| | | | | | | | folded; this will change in Python 2.4. On a 32-bit machine, this happens for 0x80000000 through 0xffffffff, and for octal constants in the same value range. No warning is issued if an explicit base is given, *or* if the string contains a sign (since in those cases no sign folding ever happens).
* Fix SF bug #683467, 'int' ability to generate longs not inheritedNeal Norwitz2003-02-101-2/+16
| | | | | | When subclassing from an int but not overriding __new__, long values were not converted properly. Try to convert longs into an int.
* Implement appropriate __getnewargs__ for all immutable subclassable builtinGuido van Rossum2003-01-291-1/+12
| | | | | | | | types. The special handling for these can now be removed from save_newobj(). Add some testing for this. Also add support for setting the 'fast' flag on the Python Pickler class, which suppresses use of the memo.
* SF # 669553, fix memory (ref) leaksNeal Norwitz2003-01-191-1/+8
| | | | Will backport.
* Since the *_Init() are private, prefix with _, suggested by SkipNeal Norwitz2002-12-311-1/+1
|
* SF #561244, Micro optimizationsNeal Norwitz2002-12-301-10/+23
| | | | | | Initialize the small integers and __builtins__ in startup. This removes some if conditions. Change XDECREF to DECREF for values which shouldn't be NULL.
* Consolidate the int and long sequence repeat code. Before the change,Neil Schemenauer2002-12-301-46/+0
| | | | integers checked for integer overflow but longs did not.
* Change int() so that passing a string, unicode, float or long argumentWalter Dörwald2002-11-191-4/+16
| | | | | | | that is outside the integer range no longer raises OverflowError, but returns a long object instead. This fixes SF bug http://www.python.org/sf/635115
* Make int("...") return a long if an int would overflow.Walter Dörwald2002-11-061-11/+13
| | | | | | Also remove the 512 character limitation for int(u"...") and long(u"..."). This closes SF bug #629989.
* Insert an overflow check when the sequence repetition count is outsideGuido van Rossum2002-09-111-3/+30
| | | | | | | the range of ints. The old code would pass random truncated bits to sq_repeat() on a 64-bit machine. Backport candidate.
* Call me anal, but there was a particular phrase that was speading toGuido van Rossum2002-08-191-1/+1
| | | | | | | comments everywhere that bugged me: /* Foo is inlined */ instead of /* Inline Foo */. Somehow the "is inlined" phrase always confused me for half a second (thinking, "No it isn't" until I added the missing "here"). The new phrase is hopefully unambiguous.
* More changes of DeprecationWarning to FutureWarning.Guido van Rossum2002-08-141-4/+4
|
* Add an improvement wrinkle to Neil Schemenauer's change to int_mulGuido van Rossum2002-08-131-2/+4
| | | | | | | (rev. 2.86). The other type is only disqualified from sq_repeat when it has the CHECKTYPES flag. This means that for extension types that only support "old-style" numeric ops, such as Zope 2's ExtensionClass, sq_repeat still trumps nb_multiply.
* int_lshift(): Simplified/sped overflow-checking.Tim Peters2002-08-111-4/+2
|
* Use a better check for overflow from a<<b.Guido van Rossum2002-08-111-2/+4
|
* Implement stage B0 of PEP 237: add warnings for operations thatGuido van Rossum2002-08-111-3/+25
| | | | | | | | | | currently return inconsistent results for ints and longs; in particular: hex/oct/%u/%o/%x/%X of negative short ints, and x<<n that either loses bits or changes sign. (No warnings for repr() of a long, though that will also change to lose the trailing 'L' eventually.) This introduces some warnings in the test suite; I'll take care of those later.
generated by cgit v0.12 at 2025-03-10 23:26:23 (GMT)