Date: Sat, 6 Oct 2012 10:21:40 -0700 (PDT)
From: Sarvi Shanmugham <sarvil...@gmail.com>
To: python-cffi@googlegroups.com
Message-Id: <45ff71c7-5ec4-4e08-9fce-ad9b5e66ed79@googlegroups.com>
In-Reply-To: <c296b987-99f5-4e07-91d2-8e51bc8f9f61@googlegroups.com>
References: <06cc3442-452d-493b-a06b-6eb039bb407f@googlegroups.com>
 <CAMSv6X1quSzE-A7zRJUU92eK2b==N7TOmLhmYxPC+-ncEn_ACw@mail.gmail.com>
 <c296b987-99f5-4e07-91d2-8e51bc8f9f61@googlegroups.com>
Subject: Re: [python-cffi] passing uint64_t integer to a function that takes
 uint64_t converts it to 32 bit
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_847_8836769.1349544100656"

------=_Part_847_8836769.1349544100656
Content-Type: multipart/alternative; 
	boundary="----=_Part_848_7676376.1349544100656"

------=_Part_848_7676376.1349544100656
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Ok. I tried this in a non-cross build environment directly on my build host.
Here is my results
>>> import cheese
>>> x=cheese.ffi.new('mytype_t *', 0x100000000)
>>> cheese.test_int64(x[0])

Data=100000000, size=8

Sizes int=4, long=8, long long=8
4294967296L
>>>                     

It seems like everything is working fine in a non-cross build environment.
I had my library print out the size of different types, and long is the 
same as "long long" on the build host

But I noticed this, the generated code is still
unsigned long _cffi_f_test_int64(unsigned long x0)
{
  return test_int64(x0);
}
But since long is the same as long long which is 64 bits, we are good.

This same code in the cross build environment produces the following
>>> print '\n%x'%cffi.test_int64(x[0])

Data=0, size=8
Sizes int=4, long=4, long long=8

0
>>>

So as I understand it using 'unsigned long' in the generated code is not 
guaranteed to be 64 bit and is machine dependent.

My build machine is 64 bit
bash-3.00$ uname -a
Linux sjc-ads-1549 2.6.9-89.0.11.ELlargesmp #1 SMP Mon Aug 31 11:05:24 EDT 
2009 x86_64 x86_64 x86_64 GNU/Linux

My target machines is also 64 bit
[128:~]$ uname -a
Linux 128.107.163.149 2.6.32.39-x8664-fsm.cge #1 SMP PREEMPT Thu Jul 5 
12:49:31 PDT 2012 x86_64 GNU/Linux


*But I suspect the reason for this difference is that all libraries are 
being compile for 32 bit*
[128:~]$ file /usr/lib/libcffitest.so
/usr/lib/libcffitest.so: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, not stripped

I use the -m32 flag to gcc for all the libraries that we compile and so 
that same is being passed to the cffi compiling as well

Sarvi


On Saturday, October 6, 2012 7:24:01 AM UTC-7, Sarvi Shanmugham wrote:
>
> The cdef contains exactly what u see in the cffitest.h file
>
> So mytype_t is defined as u_int64_t which is defined as uint64_t
>
> Yet I see the generated wrapper code use unsigned long instead of unsigned 
> long long
>
> Could this be due to a cross build environment?
>
> How do I get cffi to generate the right code?
>
> Thx
> Sarvi
>
>
------=_Part_848_7676376.1349544100656
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Ok. I tried this in a non-cross build environment directly on my build host=
.<div>Here is my results</div><div><div>&gt;&gt;&gt; import cheese</div><di=
v><div>&gt;&gt;&gt; x=3Dcheese.ffi.new('mytype_t *', 0x100000000)</div><div=
>&gt;&gt;&gt; cheese.test_int64(x[0])</div><div><br></div><div>Data=3D10000=
0000, size=3D8</div><div><br></div><div>Sizes int=3D4, long=3D8, long long=
=3D8</div><div>4294967296L</div><div>&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div></div><div><br></di=
v>It seems like everything is working fine in a non-cross build environment=
.</div><div>I had my library print out the size of different types, and lon=
g is the same as "long long" on the build host</div><div><br></div><div>But=
 I noticed this, the generated code is still</div><div><div>unsigned long _=
cffi_f_test_int64(unsigned long x0)</div><div>{</div><div>&nbsp; return tes=
t_int64(x0);</div><div>}</div></div><div>But since long is the same as long=
 long which is 64 bits, we are good.</div><div><br></div><div>This same cod=
e in the cross build environment produces the following</div><div><div>&gt;=
&gt;&gt; print '\n%x'%cffi.test_int64(x[0])</div><div><br></div><div>Data=
=3D0, size=3D8</div><div>Sizes int=3D4, long=3D4, long long=3D8</div><div><=
br></div><div>0</div><div>&gt;&gt;&gt;</div></div><div><br></div><div>So as=
 I understand it using 'unsigned long' in the generated code is not guarant=
eed to be 64 bit and is machine dependent.</div><div><br></div><div>My buil=
d machine is 64 bit</div><div>bash-3.00$ uname -a<br></div><div><div>Linux =
sjc-ads-1549 2.6.9-89.0.11.ELlargesmp #1 SMP Mon Aug 31 11:05:24 EDT 2009 x=
86_64 x86_64 x86_64 GNU/Linux</div></div><div><br></div><div>My target mach=
ines is also 64 bit</div><div><div>[128:~]$ uname -a</div><div>Linux 128.10=
7.163.149 2.6.32.39-x8664-fsm.cge #1 SMP PREEMPT Thu Jul 5 12:49:31 PDT 201=
2 x86_64 GNU/Linux</div></div><div><br></div><div><br></div><div><b>But I s=
uspect the reason for this difference is that all libraries are being compi=
le for 32 bit</b></div><div><div>[128:~]$ file /usr/lib/libcffitest.so</div=
><div>/usr/lib/libcffitest.so: ELF 32-bit LSB shared object, Intel 80386, v=
ersion 1 (SYSV), dynamically linked, not stripped</div></div><div><br></div=
><div>I use the -m32 flag to gcc for all the libraries that we compile and =
so that same is being passed to the cffi compiling as well</div><div><br></=
div><div>Sarvi</div><div><br></div><div><br>On Saturday, October 6, 2012 7:=
24:01 AM UTC-7, Sarvi Shanmugham wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">The cdef contains exactly what u see in the cffitest.h file<p>So m=
ytype_t is defined as u_int64_t which is defined as uint64_t</p><p>Yet I se=
e the generated wrapper code use unsigned long instead of unsigned long lon=
g</p><p>Could this be due to a cross build environment?</p><p>How do I get =
cffi to generate the right code?</p><p>Thx<br>Sarvi</p><p></p><p></p><p></p=
><p></p></blockquote></div>
------=_Part_848_7676376.1349544100656--

------=_Part_847_8836769.1349544100656--