[Cython] a problem with sizeof() return type

[Robert Bradshaw]

On Feb 3, 2009, at 12:01 PM, Michael Abshoff wrote:

> Lisandro Dalcin wrote:
>> Cython treats sizeof() as if it returns 'int', but IMHO it should  
>> be 'size_t'.
>
> Well, you might be technically correct since that is what the C  
> standard
> asks for, but according to various literature, i.e. for example
>
> http://publications.gbdirect.co.uk/c_book/chapter5/ 
> sizeof_and_malloc.html
>
> "The sizeof operator returns the size in bytes of its operand. Whether
> the result of sizeof is unsigned int or unsigned long is  
> implementation
> defined—which is why the declaration of malloc above ducked the  
> issue by
> omitting any parameter information; "

I think "int" is the best thing to return--it can always get coerced  
up to a size_t if needed, but the other way may prove problematic.  
Also, "int" is a more abstract (conceptually at least) type (better  
fitting with the ambiguity in the C standard), and we shouldn't have  
to worry about overflow in this case.

>> Implementing this the right way would require to make Cython  
>> recognize
>> 'size_t' as a native type, more or less in the way it already
>> recognizes 'Py_ssize_t'. What do you think about this?
>
> Mmmh, do you want to define size_t in Cython or pull it in from
> somewhere? At least for C code that ought to be rather tricky for VS6
> for example which needs to work since we are still supporting  
> Python 2.3
> on Windows. But you could work around the issue by defining size_t in
> Cython as either unsigned int, unsigned long or unsigned long long
> depending on the platform. But that could potentially clash with  
> various
> C++ runtime libs.

I am -1 on defining size_t ourselves, but would like to pull it from  
somewhere if we could.

> Do you think that people will see overflow issues? I think the  
> tradeoff
> of following the C standard here is rather high since in reality  
> size_t
> in C is rather badly handled. And if you guys decide to follow the C
> standard here someone ought to break out Python 2.6 and VS 6 and  
> verify
> that things are still working :)

For sure.

- Robert