working with ctypes and complex data structures

Michael Felt michael at felt.demon.nl
Mon Oct 3 14:06:36 EDT 2016



On 03-Oct-16 16:35, Michael Felt wrote:
>> I'd alias the type instead of defining a struct, e.g. `time_t =
>> c_long`. This preserves automatic conversion of the simple type.
> The reason for the not using alias is because a) I was trying to be 
> more inline with the text of the include file.
> I will have to check the sizeof c_long (i.e., sizeof(long) in both 32 
> and 64-bit modes
>> Also, sys.maxsize is based on the platform's size_t type. That's
>> generally the same size as a pointer, but C doesn't require this.
>> Instead use sizeof(c_void_p), which will be 8 on a 64-bit platform and
>> 4 on a 32-bit platform. 

I had checked this before - I shall have to try a 32-bit python to see 
what _ctypes is doing with c_long on AIX - is it 4, or is it 8.
michael at x071:[/data/prj/python/cloud-init/aix-cloud-init-0.7.8.1/new]cat 
xxx.c
#include <libperfstat.h>
time_t
lbolt()
{
         perfstat_cpu_total_t cpu_totals;
         void *p1, *p2;

         printf("int_size:%d\n", sizeof(int));
         printf("long_size:%d\n", sizeof(long));
         printf("timet_size:%d\n", sizeof(time_t));
         printf("void_ptr_size:%d\n", sizeof(void *));
         printf("lbolt_size:%d\n", sizeof(cpu_totals.lbolt));

         p1 = &cpu_totals;
         p2 = &cpu_totals.lbolt;
         printf("lbolt offset:%d\n", p2 - p1);
}

main()
{
         lbolt();
}

michael at x071:[/data/prj/python/cloud-init/aix-cloud-init-0.7.8.1/new]cc 
-q32 >
int_size:4
long_size:4
timet_size:4
void_ptr_size:4
lbolt_size:4
lbolt offset:192
michael at x071:[/data/prj/python/cloud-init/aix-cloud-init-0.7.8.1/new]cc 
-q64 >
int_size:4
long_size:8
timet_size:8
void_ptr_size:8
lbolt_size:8
lbolt offset:192


I think 4 and 8 because of problems I have with this block when not in 
the right "mode", i.e. SIZEOF_LONG changes

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
  * 32-bit platforms using gcc.  We try to catch that here at compile-time
  * rather than waiting for integer multiplication to trigger bogus
  * overflows.
  */
#error "LONG_BIT definition appears wrong for platform (bad gcc/glibc 
config?)."
#endif




More information about the Python-list mailing list