471,338 Members | 1,221 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,338 software developers and data experts.

In C extension .pyd, sizeof INT64 = 4?

My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?
Thanks.

Jun 12 '07 #1
12 2882
On 6 12 , 6 03 , Allen <Allen.Che...@gmail.comwrote:
My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?
Thanks.
I find it is strange. In an exe win32 console project, sizeof(INT64) =
8.

My code is just like this:

/* my.h header file */

#ifdef __cplusplus
extern "C" {
#endif

static PyObject* method(PyObject* self, PyObject *args);

#idef __cplusplus
}
#endif

/* my.cpp source file */
PyObject* method(PyObject* self, PyObject *args)
{
INT64 nValue; /* LINE_HERE */
INT32 nRet;
nRet = DoSomeCOperations(nValue);
return PyBuildValue("i", nRet);
}

If I changed INT64 nValue to be static INT64 nValue at LINE_HERE, it
is ok.
Why?
Jun 12 '07 #2
En Tue, 12 Jun 2007 08:39:43 -0300, Allen <Al**********@gmail.com>
escribió:
PyObject* method(PyObject* self, PyObject *args)
{
INT64 nValue; /* LINE_HERE */
INT32 nRet;
nRet = DoSomeCOperations(nValue);
return PyBuildValue("i", nRet);
}

If I changed INT64 nValue to be static INT64 nValue at LINE_HERE, it
is ok.
Why?
I don't know, but I don't see either where Python is involved... you don't
use any argument and the returned Python object is not an INT64...

--
Gabriel Genellina

Jun 12 '07 #3
On 6 12 , 8 08 , "Gabriel Genellina" <gagsl-...@yahoo.com.arwrote:
En Tue, 12 Jun 2007 08:39:43 -0300, Allen <Allen.Che...@gmail.com>
escribió:
PyObject* method(PyObject* self, PyObject *args)
{
INT64 nValue; /* LINE_HERE */
INT32 nRet;
nRet = DoSomeCOperations(nValue);
return PyBuildValue("i", nRet);
}
If I changed INT64 nValue to be static INT64 nValue at LINE_HERE, it
is ok.
Why?

I don't know, but I don't see either where Python is involved... you don't
use any argument and the returned Python object is not an INT64...

--
Gabriel Genellina
The problem is obviously compiler involved.
But I don't know why the sizeof INT64 is changed to be 4.

Jun 12 '07 #4
En Tue, 12 Jun 2007 10:01:47 -0300, Allen <Al**********@gmail.com>
escribió:
The problem is obviously compiler involved.
But I don't know why the sizeof INT64 is changed to be 4.
This prints 8, compiled with Visual C++ 2005 Express, Python 2.5.1, inside
a Python extension with all the normal definitions and #include's

void test(void)
{
INT64 i=1;
printf("%d\n", sizeof(i));
}

--
Gabriel Genellina

Jun 12 '07 #5
Allen schrieb:
My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?
What *is* INT64? It's not a builtin type of standard C, it isn't
defined by Microsoft C, and it isn't predefined by Python.

So it must be something that you have defined, and apparently
incorrectly. How did you define it?

Regards,
Martin
Jun 12 '07 #6
On 6 13 , 4 06 , "Martin v. Lo"wis" <mar...@v.loewis.dewrote:
Allen schrieb:
My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?

What *is* INT64? It's not a builtin type of standard C, it isn't
defined by Microsoft C, and it isn't predefined by Python.

So it must be something that you have defined, and apparently
incorrectly. How did you define it?

Regards,
Martin
Thanks for your reply.

I defined in this way:

#ifndef WIN32
typedef long long INT64;
#else
typedef __int64 INT64;
#endif

I feel it strange that when I use INT64 as local variable, it will run
error.
When I change the local variable to be static or global, it will be
ok.

Jun 13 '07 #7
On 6 13 , 9 00 , Allen <pruyu.c...@gmail.comwrote:
On 6 13 , 4 06 , "Martin v. Lo"wis" <mar...@v.loewis.dewrote:
Allen schrieb:
My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?
What *is* INT64? It's not a builtin type of standard C, it isn't
defined by Microsoft C, and it isn't predefined by Python.
So it must be something that you have defined, and apparently
incorrectly. How did you define it?
Regards,
Martin

Thanks for your reply.

I defined in this way:

#ifndef WIN32
typedef long long INT64;
#else
typedef __int64 INT64;
#endif

I feel it strange that when I use INT64 as local variable, it will run
error.
When I change the local variable to be static or global, it will be
ok.
I feel very very sorry.
It is my fault.
I used INT64 and initialize its value from PyArg_ParseTuple.
The code is PyArg_ParseTuple(args, "l", &nValue).
It should be PyArg_ParseTuple(args, "L", &nValue).

Thanks all of you.

Regars,
Allen Chen

Jun 13 '07 #8
I used INT64 and initialize its value from PyArg_ParseTuple.
The code is PyArg_ParseTuple(args, "l", &nValue).
It should be PyArg_ParseTuple(args, "L", &nValue).
That's still incorrect. For the L format flag, use PY_LONG_LONG,
not your own INT64 type. More generally: always use the type
documented in

http://docs.python.org/api/arg-parsing.html

Regards,
Martin
Jun 13 '07 #9
On 6 13 , 11 55 , "Martin v. Löwis" <mar...@v.loewis.dewrote:
I used INT64 and initialize its value from PyArg_ParseTuple.
The code is PyArg_ParseTuple(args, "l", &nValue).
It should be PyArg_ParseTuple(args, "L", &nValue).

That's still incorrect. For the L format flag, use PY_LONG_LONG,
not your own INT64 type. More generally: always use the type
documented in

http://docs.python.org/api/arg-parsing.html

Regards,
Martin
PY_LONG_LONG is decleared as __int64 on windows. There is no
difference.

Regards,
Allen Chen

Jun 13 '07 #10

On 12 jun 2007, at 12.03, Allen wrote:
My C extension works wrong, and debug it, found that sizeof (INT64) =
4, not 8.
I compile on Windows XP platform.
Please tell me how to fix it to support INT64?
Thanks.

--
http://mail.python.org/mailman/listinfo/python-list
On compilers that can gnerate both 32 and 64 bit executables, the
size of some
data types vary according to compiler options.
You are probably using a typedef long INT64;
In order for INT64 to always be 64 bits/8bytes you should declare:
typedef long long INT64;
-------------------------------------
This sig is dedicated to the advancement of Nuclear Power
Tommy Nordgren
to************@comhem.se

Jun 13 '07 #11
On 12 jun, 17:06, "Martin v. Lo"wis" <mar...@v.loewis.dewrote:
>
What *is*INT64? It's not a builtin type of standard C, it isn't
defined by Microsoft C, and it isn't predefined by Python.

So it must be something that you have defined, and apparently
incorrectly. How did you define it?
It is defined in basetsd.h, included by winnt.h; the OP should not
redefine it, and that also explains why I could compile my test
program without any problem.

--
Gabriel Genellina

Jun 13 '07 #12
Allen wrote:
On 6 13 , 11 55 , "Martin v. Löwis" <mar...@v.loewis.dewrote:
I used INT64 and initialize its value from PyArg_ParseTuple.
The code is PyArg_ParseTuple(args, "l", &nValue).
It should be PyArg_ParseTuple(args, "L", &nValue).

That's still incorrect. For the L format flag, use PY_LONG_LONG,
not your own INT64 type. More generally: always use the type
documented in

http://docs.python.org/api/arg-parsing.html

Regards,
Martin

PY_LONG_LONG is decleared as __int64 on windows. There is no
difference.
IMHO. Make your code platform independant and use your compiler capacities.

If for an 'L' argument PyArg_ParseTuple requires a PY_LONG_LONG, then give
it a PY_LONG_LONG and assign the parsed value into an INT64 after parsing.

You dont know if PY_LONG_LONG or INT64 wil not be defined differently in the
future, so use them where they are specified, do the assignment, and leave
the compiler warn you if anything become invalid in the futur.

My 2 cents.

A+

Laurent.

Jun 14 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Ben Chivers | last post: by
3 posts views Thread by Peter Sparago | last post: by
6 posts views Thread by Java and Swing | last post: by
14 posts views Thread by Josh Ferguson | last post: by
14 posts views Thread by cj | last post: by
3 posts views Thread by Tim Sprout | last post: by
6 posts views Thread by msb_6 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.