Martin v. Löwis <mar...@v.loewis.de> added the comment: This must be a duplicate report - this issue has been known for years, and Kristjan and others (including myself) volunteered to work on it, and did actually work on it.
I don't think it's necessary to have a bug report in the bug tracker for it. If you find a place that you would like to fix, just go ahead and fix it. Please keep in mind the following principles: - if a value can reasonably overflow an int, change the data type to something larger (typically Py_ssize_t) - if the value can overflow in principle, but likely won't, and it is difficult to fix the data type (e.g. because it's at a system interface), make a range check, raise a Python exception, and then SAFECAST the value. - if the value "shouldn't" overflow (i.e. you are believe from the data flow or other invariants that it can't happen), use a safecast - if you are certain that the value can't overflow (e.g. if you are converting the result of a sizeof of some structure), use a regular cast, along with a comment This leaves us with a number of cases where there are pragmatic Python limitations (such as the data type for line numbers, or the number of values when building a tuple in source) which make it impossible to get overflows in the current implementation. Such limitations should be collected in some place, and then SAFECASTs should be added, along with asserts at startup (e.g. that a certain datatype has no more than 2 bytes). ---------- nosy: +loewis _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9566> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
