summaryrefslogtreecommitdiffstats
path: root/Objects/longobject.c
Commit message (Collapse)AuthorAgeFilesLines
...
* More C++-compliance. Note especially listobject.c - to get C++ to accept theAnthony Baxter2006-04-111-8/+8
| | | | | | | | | 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.
* Patch #837242: id() for large ptr should return a long.Martin v. Löwis2006-04-101-3/+9
|
* Add PY_SSIZE_T_MIN, as suggested by Ralf W. Grosse-Kunstleve.Martin v. Löwis2006-04-051-1/+1
|
* Remove unnecessary casts in type object initializers.Georg Brandl2006-03-301-19/+19
|
* fix a comment.Armin Rigo2006-03-281-1/+1
|
* Checking in the code for PEP 357.Guido van Rossum2006-03-071-7/+42
| | | | | | 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).
* SF #1444030: Fix several potential defects found by Coverity.Hye-Shik Chang2006-03-071-1/+7
| | | | (reviewed by Neal Norwitz)
* Revert backwards-incompatible const changes.Martin v. Löwis2006-02-271-1/+1
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-55/+133
|
* As discussed on python-dev, silence three gcc-4.0.x warnings, using assert()Thomas Wouters2006-02-011-2/+9
| | | | | | | | | | | to protect against actual uninitialized usage. Objects/longobject.c: In function ‘PyLong_AsDouble’: Objects/longobject.c:655: warning: ‘e’ may be used uninitialized in this function Objects/longobject.c: In function ‘long_true_divide’: Objects/longobject.c:2263: warning: ‘aexp’ may be used uninitialized in this function Objects/longobject.c:2263: warning: ‘bexp’ may be used uninitialized in this function
* Add const to several API functions that take char *.Jeremy Hylton2005-12-101-1/+2
| | | | | | | | | | | | | | | | | | | 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 *.
* SF bug #1238681: freed pointer is used in longobject.c:long_pow().Tim Peters2005-07-171-5/+8
| | | | | | | | | | In addition, long_pow() skipped a necessary (albeit extremely unlikely to trigger) error check when converting an int modulus to long. Alas, I was unable to write a test case that crashed due to either cause. Bugfix candidate.
* SF bug #1224347: int/long unification and hex()Raymond Hettinger2005-06-291-2/+2
| | | | Hex longs now print with lowercase letters like their int counterparts.
* 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.
* Revert previous checkin on getargs 'L' code. Try to convert allMartin v. Löwis2005-03-031-1/+22
| | | | | numbers in PyLong_AsLongLong, and update test suite accordingly. Backported to 2.4.
* Patch #1024670: Support int objects in PyLong_AsUnsignedLong[Mask].Martin v. Löwis2004-09-201-0/+11
|
* long_pow(): Fix more instances of leaks in error cases.Tim Peters2004-08-301-3/+3
| | | | | Bugfix candidate -- although long_pow() is so different now I doubt a patch would apply to 2.3.
* SF patch 936813: fast modular exponentiationTim Peters2004-08-301-107/+185
| | | | | | | | | | | | | | | | | | | | | | | | This checkin is adapted from part 2 (of 3) of Trevor Perrin's patch set. BACKWARD INCOMPATIBILITY: SHIFT must now be divisible by 5. AFAIK, nobody will care. long_pow() could be complicated to worm around that, if necessary. long_pow(): - BUGFIX: This leaked the base and power when the power was negative (and so the computation delegated to float pow). - Instead of doing right-to-left exponentiation, do left-to-right. This is more efficient for small bases, which is the common case. - In addition, if the exponent is large (more than FIVEARY_CUTOFF digits), precompute [a**i % c for i in range(32)], and go left to right 5 bits at a time. l_divmod(): - The signature changed so that callers who don't want the quotient, or don't want the remainder, can pass NULL in the slot they don't want. This saves them from having to declare a vrbl for unwanted stuff, and remembering to decref it. long_mod(), long_div(), long_classic_div(): - Adjust to new l_divmod() signature, and simplified as a result.
* SF patch 936813: fast modular exponentiationTim Peters2004-08-291-21/+79
| | | | | | | | | | | | | | | | | | This checkin is adapted from part 1 (of 3) of Trevor Perrin's patch set. x_mul() - sped a little by optimizing the C - sped a lot (~2X) if it's doing a square; note that long_pow() squares often k_mul() - more cache-friendly now if it's doing a square KARATSUBA_CUTOFF - boosted; gradeschool mult is quicker now, and it may have been too low for many platforms anyway KARATSUBA_SQUARE_CUTOFF - new - since x_mul is a lot faster at squaring now, the point at which Karatsuba pays for squaring is much higher than for general mult
* 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 patch 730594: assert from longobject.c, line 1215.Tim Peters2003-05-051-4/+4
| | | | | | | | Some version of gcc in the "RTEMS port running on the Coldfire (m5200) processor" generates bad code for a loop in long_from_binary_base(), comparing the wrong half of an int to a short. The patch changes the decl of the short temp to be an int temp instead. This "simplifies" the code enough that gcc no longer blows it.
* Silence compiler warnings in VC 7.Jeremy Hylton2003-05-011-2/+2
|
* SF # 595026: support for masks in getargs.c.Thomas Heller2003-04-171-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rename LONG_LONG to PY_LONG_LONG. Fixes #710285.Martin v. Löwis2003-03-291-22/+22
|
* Fix SF bug #689659, 64-bit int and long hash keys incompatibleNeal Norwitz2003-02-231-2/+4
| | | | | On a 64-bit machine, a dictionary could contain duplicate int/long keys if the value was > 2**32.
* _PyLong_Sign(): remove an assert that needed a variable ndigits thatGuido van Rossum2003-02-031-3/+2
| | | | | | | | | wasn't used outside the assert (and hence caused a compiler warning about an unused variable in NDEBUG mode). The assert wasn't very useful any more. _PyLong_NumBits(): moved the calculation of ndigits after asserting that v != NULL.
* long_from_binary_base(): Sped this a little by computing the # of bitsTim Peters2003-02-021-6/+6
| | | | needed outside the first loop.
* Tightened a too-generous assert.Tim Peters2003-02-021-1/+1
|
* long(string, base) now takes time linear in len(string) when base is aTim Peters2003-02-021-15/+108
| | | | | power of 2. Enabled the tail end of test_long() in pickletester.py because it no longer takes forever when run from test_pickle.py.
* cPickle.c: Full support for the new LONG1 and LONG4. Added comments.Tim Peters2003-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assorted code cleanups; e.g., sizeof(char) is 1 by definition, so there's no need to do things like multiply by sizeof(char) in hairy malloc arguments. Fixed an undetected-overflow bug in readline_file(). longobject.c: Fixed a really stupid bug in the new _PyLong_NumBits. pickle.py: Fixed stupid bug in save_long(): When proto is 2, it wrote LONG1 or LONG4, but forgot to return then -- it went on to append the proto 1 LONG opcode too. Fixed equally stupid cancelling bugs in load_long1() and load_long4(): they *returned* the unpickled long instead of pushing it on the stack. The return values were ignored. Tests passed before only because save_long() pickled the long twice. Fixed bugs in encode_long(). Noted that decode_long() is quadratic-time despite our hopes, because long(string, 16) is still quadratic-time in len(string). It's hex() that's linear-time. I don't know a way to make decode_long() linear-time in Python, short of maybe transforming the 256's-complement bytes into marshal's funky internal format, and letting marshal decode that. It would be more valuable to make long(string, 16) linear time. pickletester.py: Added a global "protocols" vector so tests can try all the protocols in a sane way. Changed test_ints() and test_unicode() to do so. Added a new test_long(), but the tail end of it is disabled because it "takes forever" under pickle.py (but runs very quickly under cPickle: cPickle proto 2 for longs is linear-time).
* Squash compiler wng about signed/unsigned comparison mismatch.Tim Peters2003-01-311-1/+1
|
* _PyLong_NumBits(): The definition of this was too specific to the quirkyTim Peters2003-01-311-8/+17
| | | | | | | | | needs of pickling longs. Backed off to a definition that's much easier to understand. The pickler will have to work a little harder, but other uses are more likely to be correct <0.5 wink>. _PyLong_Sign(): New teensy function to characterize a long, as to <0, ==0, or >0.
* 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.
* Added new private API function _PyLong_NumBits. This will be used at theTim Peters2003-01-281-0/+35
| | | | | | | start for the C implemention of new pickle LONG1 and LONG4 opcodes (the linear-time way to pickle a long is to call _PyLong_AsByteArray, but the caller has no idea how big an array to allocate, and correct calculation is a bit subtle).
* Consolidate the int and long sequence repeat code. Before the change,Neil Schemenauer2002-12-301-19/+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-9/+20
| | | | | | | 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-8/+10
| | | | | | Also remove the 512 character limitation for int(u"...") and long(u"..."). This closes SF bug #629989.
* replace thread state objects' ticker and checkinterval fields with twoSkip Montanaro2002-09-031-4/+2
| | | | | | | | | | globals, _Py_Ticker and _Py_CheckInterval. This also implements Jeremy's shortcut in Py_AddPendingCall that zeroes out _Py_Ticker. This allows the test in the main loop to only test a single value. The gory details are at http://python.org/sf/602191
* long_format(), long_lshift(): Someone on c.l.py is trying to boostTim Peters2002-08-201-2/+2
| | | | | | | | | | | | SHIFT and MASK, and widen digit. One problem is that code of the form digit << small_integer implicitly assumes that the result fits in an int or unsigned int (platform-dependent, but "int sized" in any case), since digit is promoted "just" to int or unsigned via the usual integer promotions. But if digit is typedef'ed as unsigned int, this loses information. The cure for this is just to cast digit to twodigits first.
* Illustrating by example one good reason not to trust a proof <wink>.Tim Peters2002-08-151-3/+3
|
* k_mul() comments: In honor of Dijkstra, made the proof that "t3 fits"Tim Peters2002-08-151-34/+37
| | | | | | | rigorous instead of hoping for testing not to turn up counterexamples. Call me heretical, but despite that I'm wholly confident in the proof, and have done it two different ways now, I still put more faith in testing ...
* long_mul(): Simplified exit code. In particular, k_mul() returns aTim Peters2002-08-151-9/+3
| | | | | normalized result, so no point to normalizing it again. The number of test+branches was also excessive.
* k_mul() comments: Simplified the simplified explanation of why ah*bh andTim Peters2002-08-141-6/+3
| | | | al*bl "always fit": it's actually trivial given what came before.
* k_mul() comments: Explained why there's always enough room to subtractTim Peters2002-08-141-0/+7
| | | | | | ah*bh and al*bl. This is much easier than explaining why that's true for (ah+al)*(bh+bl), and follows directly from the simple part of the (ah+al)*(bh+bl) explanation.
* Fixed error in new comment.Tim Peters2002-08-131-4/+3
|
* k_mul(): The fix for (ah+al)*(bh+bl) spilling 1 bit beyond the allocatedTim Peters2002-08-131-8/+44
| | | | | | | | | | space is no longer needed, so removed the code. It was only possible when a degenerate (ah->ob_size == 0) split happened, but after that fix went in I added k_lopsided_mul(), which saves the body of k_mul() from seeing a degenerate split. So this removes code, and adds a honking long comment block explaining why spilling out of bounds isn't possible anymore. Note: ff we end up spilling out of bounds anyway <wink>, an assert in v_iadd() is certain to trigger.
* Fix comment for PyLong_AsUnsignedLong() to say that the return valueGuido van Rossum2002-08-131-1/+1
| | | | is an *unsigned* long.
* k_lopsided_mul(): This allocated more space for bslice than necessary.Tim Peters2002-08-121-1/+1
|
* Added new function k_lopsided_mul(), which is much more efficient thanTim Peters2002-08-121-10/+72
| | | | | | | | k_mul() when inputs have vastly different sizes, and a little more efficient when they're close to a factor of 2 out of whack. I consider this done now, although I'll set up some more correctness tests to run overnight.
* k_mul(): Moved an assert down. In a debug build, interrupting aTim Peters2002-08-121-2/+2
| | | | | multiply via Ctrl+C could cause a NULL-pointer dereference due to the assert.