[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
Travis Oliphant
oliphant.travis at ieee.org
Tue Aug 22 15:30:54 EDT 2006
Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for
> NPY_INT is 5
> NPY_LONG is 7
>
> to match overloaded function I need to check these type values.
>
> On 64bit all works fine:
> my 32bit int function matches NPY_INT - which is "int" in C/C++
> my 64bit int function matches NPY_LONG - which is "long" in C/C++
>
> but on 32bit Linux
> the 32bit int function matches NPY_LONG
> there is no NPY_INT on 32bit
>
Yes there is. Both NPY_INT and NPY_LONG are always there. One matches
the int and one matches the long.
Perhaps you are confused about what the special defines NPY_INT32 match to?
The behavior is that the 'long' type gets "first-dibs" then the
'longlong' type gets a crack. Finally, the 'int' type is chosen. The
first one that matches the bit-type is used.
> that is: if I have a non overloaded C/C++ function that expects a C "int"
> - i.e. a 32bit int - I have write different function matching rules !!!
>
What you need to do is stop trying to match bit-widths and instead match
c-types. That's why NPY_INT and NPY_LONG are both there.
Let me know if you have further questions. I don't really understand
what the issue is.
-Travis
More information about the NumPy-Discussion
mailing list