summaryrefslogtreecommitdiffstats
path: root/Objects/longobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Backport of several functions from Python 3.0 to 2.6 including ↵Christian Heimes2008-01-251-165/+165
| | | | | | | PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t. The functions are partly required for the backport of the bytearray type and _fileio module. They should also make it easier to port C to 3.0. First chapter of the Python 3.0 io framework back port: _fileio The next step depends on a working bytearray type which itself depends on a backport of the nwe buffer API.
* Silence Coverity false alerts with CIDs #172, #183, #184Christian Heimes2008-01-181-0/+1
|
* Continue rolling back pep-3141 changes that changed behavior from 2.5. ThisJeffrey Yasskin2008-01-051-34/+0
| | | | | | | | | | | | round included: * Revert round to its 2.6 behavior (half away from 0). * Because round, floor, and ceil always return float again, it's no longer necessary to have them delegate to __xxx___, so I've ripped that out of their implementations and the Real ABC. This also helps in implementing types that work in both 2.6 and 3.0: you return int from the __xxx__ methods, and let it get enabled by the version upgrade. * Make pow(-1, .5) raise a ValueError again.
* Make math.{floor,ceil}({int,long}) return float again for backwardsJeffrey Yasskin2008-01-041-2/+2
| | | | compatibility after r59671 made them return integral types.
* Bug #1481296: Fixed long(float('nan'))!=0L.Christian Heimes2008-01-041-0/+3
|
* Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (justJeffrey Yasskin2008-01-031-15/+67
| | | | | | | the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361, r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new documentation. The only significant difference is that round(x) returns a float to preserve backward-compatibility. See http://bugs.python.org/issue1689.
* #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and ↵Christian Heimes2007-12-191-89/+89
| | | | Py_REFCNT. Macros for b/w compatibility are available.
* Issue #1772851. Alters long.__hash__ from being *almost* completelyFacundo Batista2007-09-191-0/+8
| | | | | | | predictable to being completely predictable. The value of hash(n) is unchanged for any n that's small enough to be representable as an int, and also unchanged for the vast majority of long integers n of reasonable size.
* PEP 3123: Provide forward compatibility with Python 3.0, while keepingMartin v. Löwis2007-07-211-89/+89
| | | | | backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT.
* Fix problems in x64 build that were discovered by the testsuite:Kristján Valur Jónsson2007-05-031-1/+1
| | | | | | | | | | | | - 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.
* Add some missing NULL checks which trigger crashes on low-memory conditions.Georg Brandl2007-04-111-0/+8
| | | | Found by Victor Stinner. Will backport when 2.5 branch is unfrozen.
* Patch #1638879: don't accept strings with embedded NUL bytes in long().Georg Brandl2007-03-061-1/+18
|
* 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.
* Forward-port of r52136,52138: a review of overflow-detecting code.Armin Rigo2006-10-041-24/+47
| | | | | | | | | | | | | | | | | | | | | | | * 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...
* Patch #1538606, Patch to fix __index__() clipping.Neal Norwitz2006-08-121-42/+7
| | | | | | | 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.
* Move the initialization of size_a down below the check for a being NULL.Neal Norwitz2006-07-231-1/+2
| | | | Reported by Klocwork #106
* a & b were dereffed above, so they are known to be valid pointers.Neal Norwitz2006-07-161-3/+2
| | | | | | z is known to be NULL, nothing to DECREF. Reported by Klockwork, #107.
* PyLong_FromString(): Continued fraction analysis (explained inTim Peters2006-05-301-3/+74
| | | | | | | | | | | | a new comment) suggests there are almost certainly large input integers in all non-binary input bases for which one Python digit too few is initally allocated to hold the final result. Instead of assert-failing when that happens, allocate more space. Alas, I estimate it would take a few days to find a specific such case, so this isn't backed up by a new test (not to mention that such a case may take hours to run, since conversion time is quadratic in the number of digits, and preliminary attempts suggested that the smallest such inputs contain at least a million digits).
* Patch #1494387: SVN longobject.c compiler warningsTim Peters2006-05-251-1/+1
| | | | | | | | | The SIGCHECK macro defined here has always been bizarre, but it apparently causes compiler warnings on "Sun Studio 11". I believe the warnings are bogus, but it doesn't hurt to make the macro definition saner. Bugfix candidate (but I'm not going to bother).
* Faster path for PyLong_FromLongLong, using PyLong_FromLong algorithmBob Ippolito2006-05-251-10/+50
|
* A new table to help string->integer conversion was added yesterday toTim Peters2006-05-251-14/+13
| | | | | | both mystrtoul.c and longobject.c. Share the table instead. Also cut its size by 64 entries (they had been used for an inscrutable trick originally, but the code no longer tries to use that trick).
* Heavily fiddled variant of patch #1442927: PyLong_FromString optimization.Tim Peters2006-05-241-44/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``long(str, base)`` is now up to 6x faster for non-power-of-2 bases. The largest speedup is for inputs with about 1000 decimal digits. Conversion from non-power-of-2 bases remains quadratic-time in the number of input digits (it was and remains linear-time for bases 2, 4, 8, 16 and 32). Speedups at various lengths for decimal inputs, comparing 2.4.3 with current trunk. Note that it's actually a bit slower for 1-digit strings: len speedup ---- ------- 1 -4.5% 2 4.6% 3 8.3% 4 12.7% 5 16.9% 6 28.6% 7 35.5% 8 44.3% 9 46.6% 10 55.3% 11 65.7% 12 77.7% 13 73.4% 14 75.3% 15 85.2% 16 103.0% 17 95.1% 18 112.8% 19 117.9% 20 128.3% 30 174.5% 40 209.3% 50 236.3% 60 254.3% 70 262.9% 80 295.8% 90 297.3% 100 324.5% 200 374.6% 300 403.1% 400 391.1% 500 388.7% 600 440.6% 700 468.7% 800 498.0% 900 507.2% 1000 501.2% 2000 450.2% 3000 463.2% 4000 452.5% 5000 440.6% 6000 439.6% 7000 424.8% 8000 418.1% 9000 417.7%
* Fix problems found by Coverity.Neal Norwitz2006-05-101-4/+4
| | | | | | | | | | | | | longobject.c: also fix an ssize_t problem <a> could have been NULL, so hoist the size calc to not use <a>. _ssl.c: under fail: self is DECREF'd, but it would have been NULL. _elementtree.c: delete self if there was an error. _csv.c: I'm not sure if lineterminator could have been anything other than a string. However, other string method calls are checked, so check this one too.
* C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in ↵Skip Montanaro2006-04-181-2/+2
| | | | a couple places
* Fix int() and long() to repr() their argument when formatting the exception,Thomas Wouters2006-04-111-2/+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-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.
generated by cgit v0.12 at 2024-10-24 00:33:56 (GMT)