Robert Bradshaw wrote:
> On Nov 5, 2009, at 2:31 AM, Dag Sverre Seljebotn wrote:
>> For talking with C++, the C++ compiler deals with it.
>>
>> For Cython-specific/C-only, I think we should seriously consider
>> disallowing overloading based on size. We simply don't allow
>>
>> cdef foo(double x)
>> cdef foo(float x)
>>
>> But let's cross that bridge when we come to it...
> 
> Well,
> 
> cdef long max(long a, long b)
> cdef int max(int a, int b)
> 
> and
> 
> cdef float sin(float)
> cdef double sin(double)
> 
> May both come in handy, but abuse of overloading based on size could  
> be really nasty. (I don't think this is specific to Cython, but to  
> writing portable code in general.)

I hope templates can deal with most of these cases.

>> Hmm. But today, this would lead to a bug on 32-bit Linux:
>>
>> cdef extern from "header.h":
>>     ctypedef short my_longlong # really long long
>>
>> cdef my_longlong f(my_longlong x):
>>     return x // 2
>>
>> I'm pretty sure this would result in 32-bit division rather than 64- 
>> bit.
> 

Actually, "int" will have the same problem and is much less obvious 
(because the "2" literal is apparently "long", which I guess trumps "int").

> Yes, that's true, and I could be bad (though only if you're storing  
> values larger than shorts, in which case the extern definition is  
> clearly wrong, though that might not always be obvious).


Well, if you know that short is 16 bits long, then the problem is a bit 
different. You don't in general with a C compiler (although I don't know 
of any exceptions personally).

(I was wondering if I should suggest doing like Java and *define* short 
to be 16 bits while we have the chance, but I guess it would only bring 
confusion and we can always support int16_t in C99).

-- 
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to