passing uint64_t integer to a function that takes uint64_t converts it to 32 bit - python-cffi

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion passing uint64_t integer to a function that takes uint64_t converts it to 32 bit
Received-SPF: pass (google.com: domain of hakan.a...@gmail.com designates 209.85.210.49 as permitted sender) client-ip=209.85.210.49;
MIME-Version: 1.0
Sender: hakan.a...@gmail.com
In-Reply-To: <f28eb72a-5b8d-491d-aa2b-05e1281e058e@googlegroups.com>
References: <06cc3442-452d-493b-a06b-6eb039bb407f@googlegroups.com>
	<CAMSv6X1quSzE-A7zRJUU92eK2b==N7TOmLhmYxPC+-ncEn_...@mail.gmail.com>
	<c296b987-99f5-4e07-91d2-8e51bc8f9f61@googlegroups.com>
	<45ff71c7-5ec4-4e08-9fce-ad9b5e66ed79@googlegroups.com>
	<83213abf-3981-4b9f-89db-f553a2d6b7c5@googlegroups.com>
	<5dcb95ee-53bf-497a-b3d2-c9bcba27ba88@googlegroups.com>
	<CAMSv6X1U+oCwL77DhBaYXJD4JzeGmAf30sb0m5LXL=F=YG2...@mail.gmail.com>
	<d5935193-37e5-4afa-b46b-63ce35b40b17@googlegroups.com>
	<bfb16ac1-b902-4a8a-b835-73a5b1d9bebc@googlegroups.com>
	<274ed9ee-6c3a-4efb-afaf-2ce8aacd5275@googlegroups.com>
	<f28eb72a-5b8d-491d-aa2b-05e1281e058e@googlegroups.com>
Date: Wed, 10 Oct 2012 09:52:44 +0200
Message-ID: <CAEkL+Rjv61ipr0amB614cNO_o=X8u_mHKHFn5azU2gK26p0...@mail.gmail.com>
Subject: Re: [python-cffi] passing uint64_t integer to a function that takes
 uint64_t converts it to 32 bit
From: Hakan Ardo <ha...@debian.org>
To: python-cffi@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
cross compilation support would be nice :) For what it's worth, the
hack used by configure to figure out the sizes from a cross compiler
is to try to compile snippets like:

int main() {
    static int test_array [1 - 2 * !(sizeof(long) >=3D 8)];
    test_array [0] =3D 0;
    return 0;
}

and check if the compilation was successful. It will fail to compile
if sizeof(long) is less than 8 as the length of test_array then
becomes negative. Configure performs a binary search to find the exact
size from such compilation tests.

On Wed, Oct 10, 2012 at 8:11 AM, Sarvi Shanmugham <sarvil...@gmail.com> wro=
te:
> I realized fixing/using just intN_t would not address the size of pointer=
s,
> size_t, etc
> So I went with an approach of defining a cross_target driven dictionary o=
f
> primitve types and sizes
>
> Here is a patch proposal to fix the cross compilation issue
> It uses a CFFI_CROSSTARGET environment variable to  specify what the targ=
et
> platform is
> and defines the dictionary nonstandard_integer_types according to the
> target.
>
> This cross dictionary can be expanded to more CPU architectures in the
> futures.
>
> And since this is the portion that addresses what primitive types are use=
d
> in the generated code
>
> I have talked to people who understand cross compilation better than me, =
and
> so far as I can tell haven't heard anyone use emulators.
> I have heard of cases where they use target specific headers or other fil=
es
> are specific organized by target that used based on the specific target
> being built
> But non on emulators.
>
> The solution below fits that category.
>
> It solves my cross compilation problem and seems like right solution for
> cross compilation.
> Hopefully this will help others doing cross compilation as well.
>
> Let me know if you see any holes in this.
>
> Thx,
> Sarvi
>
> bash-3.00$ hg diff
> diff -r 4f6eec10c1b2 cffi/api.py
> --- a/cffi/api.py       Thu Sep 27 19:02:00 2012 +0200
> +++ b/cffi/api.py       Tue Oct 09 22:40:47 2012 -0700
> @@ -1,5 +1,55 @@
> +import os
>  import types
>
> +cross_by_size=3D{
> +    'linux-x86_64': {
> +        1 : 'char',
> +        2 : 'short',
> +        4 : 'int',
> +        8 : 'long',
> +    },
> +    'linux-i686':   {
> +        1 : 'char',
> +        2 : 'short',
> +        4 : 'int',
> +        8 : 'long long',
> +    },
> +}
> +
> +UNSIGNED =3D 0x1000
> +cross_nonstandard_integer_types =3D{
> +    'linux-x86_64': {
> +        'int8_t'    : 1,
> +        'uint8_t'   : 1 | UNSIGNED,
> +        'int16_t'   : 2,
> +        'uint16_t'  : 2 | UNSIGNED,
> +        'int32_t'   : 4,
> +        'uint32_t'  : 4 | UNSIGNED,
> +        'int64_t'   : 8,
> +        'uint64_t'  : 8 | UNSIGNED,
> +        'intptr_t'  : 8,
> +        'uintptr_t' : 8 | UNSIGNED,
> +        'ptrdiff_t' : 8,
> +        'size_t'    : 8 | UNSIGNED,
> +        'ssize_t'   : 8,
> +    },
> +    'linux-i686':   {
> +        'int8_t'    : 1,
> +        'uint8_t'   : 1 | UNSIGNED,
> +        'int16_t'   : 2,
> +        'uint16_t'  : 2 | UNSIGNED,
> +        'int32_t'   : 4,
> +        'uint32_t'  : 4 | UNSIGNED,
> +        'int64_t'   : 8,
> +        'uint64_t'  : 8 | UNSIGNED,
> +        'intptr_t'  : 4,
> +        'uintptr_t' : 4 | UNSIGNED,
> +        'ptrdiff_t' : 4,
> +        'size_t'    : 4 | UNSIGNED,
> +        'ssize_t'   : 4,
> +    },
> +}
> +
>  class FFIError(Exception):
>      pass
>
> @@ -59,10 +109,16 @@
>                  setattr(self, name, getattr(backend, name))
>          #
>          lines =3D []
> -        by_size =3D {}
> -        for cname in ['long long', 'long', 'int', 'short', 'char']:
> -            by_size[self.sizeof(cname)] =3D cname
> -        for name, size in
> self._backend.nonstandard_integer_types().items():
> +        crosstarget=3Dos.environ.get('CFFI_CROSSTARGET', None)
> +        if crosstarget:
> +            by_size=3Dcross_by_size[crosstarget]
> +
> nonstandard_integer_types=3Dcross_nonstandard_integer_types[crosstarget]
> +        else:
> +            by_size =3D {}
> +            for cname in ['long', 'long long', 'int', 'short', 'char']:
> +                by_size[self.sizeof(cname)] =3D cname
> +
> nonstandard_integer_types=3Dself._backend.nonstandard_integer_types()
> +        for name, size in nonstandard_integer_types.items():
>              if size & 0x1000:   # unsigned
>                  equiv =3D 'unsigned %s'
>                  size &=3D ~0x1000
>
>
> On Monday, October 8, 2012 9:34:46 PM UTC-7, Sarvi Shanmugham wrote:
>>
>> I did a further bit of digging into the _cffi_backend.c code.
>>
>> Correct me if I am wrong here.
>>
>> I realize there should be no problem when the cdefs use char, short, int=
,
>> long or long long as the sizes are figured when the code actually runs o=
n
>> the target from the _cffi_backend.so. And since _cffi_backend.so is comp=
iled
>> for the target in 64 or 32 bit mode, they map to all the right sizes for=
 the
>> target platform and 64 Vs 32 bit mode as well.
>>
>> That leaves us with the problem at hand limited to the use of intN_t and
>> uintN_t relating to how the generated C code looks like.
>> And this generated C code is where the problem is. Because this generate=
d
>> code is all about the size of these types on the target.
>>
>> But here, if the cdef used int or long or such standard types, then the
>> generated code can use those same exact types without any problem I woul=
d
>> think.
>> The compiler and the compiler flags such as -m32 will take care of this
>> when that code gets compiled.
>>
>> Its only for the intN_t and the uintN_t that you need to figure what the
>> right size/type would be on the target.
>> And that too only because you are trying to map intN_t to one of the bas=
ic
>> types, like char, short, int/long, long/longlong
>>
>> I see 2 ways to make this work. I don't understand that the lateral issu=
es
>> with these different approaches will be
>>
>> Option 1:
>>    1. for intN_t and uintN_t the generated code uses intN_t and uintN_t
>> from stdint.h. And everything else can stay the same.
>>    2. Have and ENVIRONMENT variable or command setup.py/build command li=
ne
>> option like --enable-32-bit that tells the cffi code generated how intN_=
t
>> should be mapped to basic types.
>>
>> If you can give me some pointers on which way you prefer I could give it=
 a
>> shot and see how it turns out.
>>
>> Sarvi
>>
>>
>> On Sunday, October 7, 2012 7:51:57 PM UTC-7, Sarvi Shanmugham wrote:
>>>
>>> Though I think cffi intN_t should map to stdint.h intN_t
>>>
>>> I understand u will still have problem with basic int/ long and what si=
ze
>>> they should map to on the target.
>>>
>>> Is there simpler way, without resorting to emulators.
>>> http://www.mesa3d.org/autoconf.html
>>>
>>> According to the above link, we should be using ./configure --build=3D.=
....
>>> --host=3D... --target=3D...  --enable-32-bit
>>> In autoconf, the --enable-32-bit allows you to force the -m32 flag to g=
cc
>>> get 32 bit compatible binaries even though the target is 64 bit
>>>
>>> Shouldn't we have something equivalent to --target and --enable-32-bit
>>> for cffi code generation and compilation.
>>>
>>> Sarvi
>
> --
> -- python-cffi: To unsubscribe from this group, send email to
> python-cffi+unsubscribe@googlegroups.com. For more options, visit this gr=
oup
> at https://groups.google.com/d/forum/python-cffi?hl=3Den
>
>



--=20
H=E5kan Ard=F6
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
