On Feb 7, 2009, at 3:09 PM, Lisandro Dalcin wrote: > On Sat, Feb 7, 2009 at 6:13 PM, Stefan Behnel <[email protected]> > wrote: >> Hi, >> >> Lisandro Dalcin wrote: >>> Could we assume that PY_LONG_LONG is the widest integral?? Should we >>> assume that 'Py_ssize_t' and 'size_t' are between 'long' and >>> 'PY_LONG_LONG'? >> >> For starters, Py_ssize_t is defined as a signed size_t according >> to PEP >> 353. However, it does not mention a relation to PY_LONG_LONG. >> >> I would at least expect Py_ssize_t to be <= PY_LONG_LONG (the >> latter being >> the largest available type), and my (limited) knowledge about the >> "long" >> type makes me assume that it should be <= Py_ssize_t. So, yes, I >> would expect >> >> long <= Py_ssize_t <= PY_LONG_LONG >> >> and >> >> unsigned long <= size_t <= unsigned PY_LONG_LONG >> > > I think the same... Then I'll review this and push fixes.
Excellent. > >> >>> However, I'm not sure how to we will handle code like the one below >>> with the current implementation, >>> >>> cdef f(): >>> cdef Py_ssize_t a = 5 >>> cdef size_t b = 7 >>> return a + b >>> >>> I believe the value of 'a+b' should be promoted to 'signed long >>> long', >>> but it cannot see the way to implent such behavior in the current >>> Cython codebase. >> > > Well, I was partially wrong in the above comments... > >> Wouldn't Py_ssize_t be a suitable target type? Admittedly, it's << >> size_t >> for non-negative types, but the missing bit shouldn't matter in >> almost all >> cases. > > It will not matter until you get a segfault or strange results... ;-) > > >> And if users really need to make use of it, I'm fine with requiring >> them to write >> >> return <PY_LONG_LONG>a + <PY_LONG_LONG>b >> > > Yes, you are right, but then better for users to not forget the > casts... > > In short, If we can do it better, go for it and push testcases > +fixes... This is like asking if someone does cdef unsigned int a cdef int b return a + b I don't think a + b should be "upgraded" to a long (which may not even be bigger), just because it might overflow. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
