[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

Travis Oliphant oliphant.travis at ieee.org
Tue Aug 22 14:30:54 CDT 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.


More information about the Numpy-discussion mailing list