summaryrefslogtreecommitdiffstats
path: root/Objects/longobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Recorded merge of revisions 81029 via svnmerge fromAntoine Pitrou2010-05-091-2701/+2701
| | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r81029 | antoine.pitrou | 2010-05-09 16:46:46 +0200 (dim., 09 mai 2010) | 3 lines Untabify C files. Will watch buildbots. ........
* Merged revisions 74769 via svnmerge fromMark Dickinson2009-09-131-9/+11
| | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r74769 | mark.dickinson | 2009-09-13 12:56:13 +0100 (Sun, 13 Sep 2009) | 3 lines Fix potential signed-overflow bug in _PyLong_Format; also fix a couple of whitespace issues. ........
* Merged revisions 74689 via svnmerge fromMark Dickinson2009-09-061-1/+0
| | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r74689 | mark.dickinson | 2009-09-06 21:51:37 +0100 (Sun, 06 Sep 2009) | 1 line Remove redundant assignment ........
* PyLong_BASE_TWODIGITS_TYPE should be BASE_TWODIGITS_TYPEMark Dickinson2009-03-201-2/+2
|
* Merged revisions 68974-68975 via svnmerge fromMark Dickinson2009-01-261-8/+9
| | | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r68974 | mark.dickinson | 2009-01-26 21:36:30 +0000 (Mon, 26 Jan 2009) | 4 lines Fix undefined behaviour (left shift of negative value) in long_hash. Also, rewrap a line of length > 79, and update comments. ........ r68975 | mark.dickinson | 2009-01-26 21:40:08 +0000 (Mon, 26 Jan 2009) | 2 lines Fix comment. ........
* Merged revisions 68947 via svnmerge fromMark Dickinson2009-01-251-1/+1
| | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r68947 | mark.dickinson | 2009-01-25 22:12:31 +0000 (Sun, 25 Jan 2009) | 3 lines No need for carry to be type twodigits in _PyLong_AsByteArray; digit is large enough. This change should silence a compiler warning on Windows. ........
* Merged revisions 68890 via svnmerge fromMark Dickinson2009-01-241-23/+20
| | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r68890 | mark.dickinson | 2009-01-24 15:27:44 +0000 (Sat, 24 Jan 2009) | 6 lines Issue #4393: fix 3 classes of potential portability problems in longobject.c: - fix some places where counters into ob_digit were declared as int instead of Py_ssize_t - add (twodigit) casts where necessary - fix code in _PyLong_AsByteArray that uses << on negative values ........
* Issue #1481296: (again!) Make conversion of a float NaN to an int orMark Dickinson2008-08-041-2/+4
| | | | | | | long raise ValueError instead of returning 0. Also, change the error message for conversion of an infinity to an integer, replacing 'long' by 'integer', so that it's appropriate for both long(float('inf')) and int(float('inf')).
* Security patches from Apple: prevent int overflow when allocating memoryNeal Norwitz2008-07-311-0/+2
|
* Added additional __sizeof__ implementations and addressed comments made inRobert Schuppenies2008-07-101-2/+2
| | | | Issue3122.
* Revert 64424, 64438, and 64439.Raymond Hettinger2008-06-241-7/+0
|
* Make bin() implementation parallel oct() and hex() so that int/long ↵Raymond Hettinger2008-06-201-0/+7
| | | | subclasses can override or so that other classes can support.
* This reverts r63675 based on the discussion in this thread:Gregory P. Smith2008-06-091-16/+16
| | | | | | | http://mail.python.org/pipermail/python-dev/2008-June/079988.html Python 2.6 should stick with PyString_* in its codebase. The PyBytes_* names in the spirit of 3.0 are available via a #define only. See the email thread.
* Some style nits. Also clarify in the docstrings what __sizeof__ does.Georg Brandl2008-06-011-1/+1
|
* Issue #2898: Added sys.getsizeof() to retrieve size of objects in bytes.Robert Schuppenies2008-06-011-0/+13
|
* Refactor and clean up str.format() code (and helpers) in advance of ↵Eric Smith2008-05-301-16/+11
| | | | optimizations.
* Renamed PyString to PyBytesChristian Heimes2008-05-261-17/+17
|
* I finally got the time to update and merge Mark's and my trunk-math branch. ↵Christian Heimes2008-04-181-0/+12
| | | | | | The patch is collaborated work of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and edge cases related to operations with NaN, INF, very small values and complex math. The patch also adds acosh, asinh, atanh, log1p and copysign to all platforms. Finally it fixes differences between platforms like different results or exceptions for edge cases. Have fun :)
* Fix for possible signed overflow: the behaviour of -LONG_MIN isMark Dickinson2008-04-151-6/+19
| | | | undefined in ANSI C.
* Revert r61969 which added casts to Py_CHARMASK to avoid compiler warnings.Neal Norwitz2008-03-281-5/+5
| | | | | | Rather than sprinkle casts throughout the code, change Py_CHARMASK to always cast it's result to an unsigned char. This should ensure we do the right thing when accessing an array with the result.
* Fix warnings about using char as an array subscript. This is not portableNeal Norwitz2008-03-271-5/+5
| | | | since char is signed on some platforms and unsigned on others.
* Fix build on platforms that don't have intptr_t. Patch by Joseph Armbruster.Jeffrey Yasskin2008-03-181-1/+1
|
* Finished backporting PEP 3127, Integer Literal Support and Syntax.Eric Smith2008-03-171-1/+14
| | | | | | | | Added 0b and 0o literals to tokenizer. Modified PyOS_strtoul to support 0b and 0o inputs. Modified PyLong_FromString to support guessing 0b and 0o inputs. Renamed test_hexoct.py to test_int_literal.py and added binary tests. Added upper and lower case 0b, 0O, and 0X tests to test_int_literal.py
* Backport of PEP 3101, Advanced String Formatting, from py3k.Eric Smith2008-02-171-0/+36
| | | | | | | | | | | | | | | Highlights: - Adding PyObject_Format. - Adding string.Format class. - Adding __format__ for str, unicode, int, long, float, datetime. - Adding builtin format. - Adding ''.format and u''.format. - str/unicode fixups for formatters. The files in Objects/stringlib that implement PEP 3101 (stringdefs.h, unicodedefs.h, formatter.h, string_format.h) are identical in trunk and py3k. Any changes from here on should be made to trunk, and changes will propogate to py3k).
* Added PyNumber_ToBase and supporting routines _PyInt_Format andEric Smith2008-02-101-14/+23
| | | | | | | | | | | | | | | | | _PyLong_Format. In longobject.c, changed long_format to _PyLong_Format. In intobject.c, changed uses of PyOS_snprintf to _PyInt_Format instead. _PyLong_Format is similar to py3k's routine of the same name, except it has 2 additional parameters: addL and newstyle. addL was existing in long_format, and controls adding the trailing "L". This is unneeded in py3k. newstyle is used to control whether octal prepends "0" (the pre-2.6 style), or "0o" (the 3.0 sytle). PyNumber_ToBase is needed for PEP 3127 (Integer Literal Support and Syntax) and PEP 3101 (Advanced String Formatting). This changeset does not need merging into py3k.
* 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.)
generated by cgit v0.12 at 2024-10-23 12:35:08 (GMT)