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

[Sebastian Haase]

Thanks for the reply, see question below...
On Tuesday 22 August 2006 12:30, Travis Oliphant wrote:
> 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.
>
This explains it - my specific function overloads only one of its two array 
arguments (i.e. allow many different types)  - the second one must be a 
C "int".    [(a 32bit int) - but SWIG  matches the "C signature" ] 
But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
But on 32bitLinux I get NPY_LONG because of that rule.

My SWIG typemaps want to "double check" that a C function expecting c-type 
"int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 

I don't know what the solution should be  - but maybe the rule should be 
changed based on the assumption that "int" in more common !?


> > 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.
If you are referring to use of the sizeof() operator - I'm not doing that.

Thanks as always for your quick and careful replies.
- Sebastian