[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
haase at msg.ucsf.edu
Tue Aug 22 15:44:32 CDT 2006
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.
More information about the Numpy-discussion