On Feb 7, 2009, at 1:13 PM, Stefan Behnel 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 this is the right ordering for us to make. As we want to produce C files often destined to be compiled on other architectures, we can't actually test to see the order. >> 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. > > 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. 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 Actually, the target should be size_t, following the C standard that operations between signed and unsigned have an unsigned result. But we certainly shouldn't be promoting it to a new type. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
