[Cython] problems with C numeric types

[Robert Bradshaw]

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