William Stein wrote: > On 10/28/07, Jaap Spies <[EMAIL PROTECTED]> wrote: >>> Py_ssize_t should *never* be used if you really mean to use an >>> int. But in any situation that you're indexing something, use >>> it. Note that it is not just size_t from C, since it is signed, >>> since in Python list indices can be negative (in which case counting >>> starts from the right side of the list). >>> >> As I wrote, I see a lot of cdef Py_ssize_t in for example matrix2.pyx >> that should be cdef int. > > >> I did change some of them in trac #217, but I think a new trac >> ticket should be created. > > > Are you sure? I just had a look at trac #217, and your changing Py_ssize_t > into int specifically *introduces* bugs into that code. E.g., suppose the > input > were a 1 x 2^33 matrix. Then you did this in your patch: > > - cdef Py_ssize_t m, n, r > + cdef int m, n, r > > Lower down one has: > m = self._nrows > n = self._ncols > > Now, instead if the code working like it used to, there will be an overflow, > and one will get total nonsense. > > William > > > >
--~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
