[PATCH][win32] problems compiling bzrlib/_dirstate_helpers_c.pyx with MSVC

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lukáš Lalinský пишет:
> On St, 2007-08-01 at 12:49 +0200, Lukáš Lalinský wrote:
>> On St, 2007-08-01 at 13:39 +0300, Alexander Belchenko wrote:
>>> Lukáš Lalinský пишет:
>>>> On Ut, 2007-07-31 at 12:13 +0300, Alexander Belchenko wrote: 
>>>>> I don't know is it bug in Pyrex or in our usage of Pyrex, but I repeat
>>>>> one more time:
>>>>>
>>>>> 	Pyrex substitute intptr_t with int in
>>>>> 	generated C-code, so actually nor stdint.h nor intptr_t
>>>>> 	is not used at all.
>>>>>
>>>>> intptr_t is not present in generated C-code. So, it's already
>>>>> breaks compatibility with 64-bit platform.
>>>> If the ctypedef statement appears in a 'cdef extern from' section it
>>>> will not be replaced. This happens only if it's moved to the top-level
>>>> block.
>>>>
>>>> For example my compiled _dirstate_helpers_c.c contains:
>>>>
>>>>   __pyx_r = ((((intptr_t )__pyx_v_ptr) & ((sizeof(int )) - 1)) == 0);
>>> Lukáš, what version of Pyrex you are using?
>> 0.9.3.1 on Windows, 0.9.4.1 on Linux. But I've just noticed that the
>> newer version on Linux indeed replaces intptr_t with int. I personally
>> think this behavior is wrong, but I'm really not sure if it's a
>> regression or a new feature.
> 
> After some experiments, it seems to be a bug. For example for this Pyrex
> code:
> 
> cdef extern from "stdint.h":
>     ctypedef char intptr_t
> 
> cdef int test():
>     cdef intptr_t a
>     a = 1
>     return <intptr_t>a == 0
> 
> It generates this C code:
> 
> static int __pyx_f_4test_test(void) {
>   intptr_t __pyx_v_a;
>   int __pyx_r;
> 
>   /* "/home/lukas/projects/bzr/bzr/bzr.dev/bzrlib/test.pyx":6 */
>   __pyx_v_a = 1;
> 
>   /* "/home/lukas/projects/bzr/bzr/bzr.dev/bzrlib/test.pyx":7 */
>   __pyx_r = (((char )__pyx_v_a) == 0);
>   goto __pyx_L0;
> 
>   __pyx_r = 0;
>   goto __pyx_L0;
>   __pyx_L1:;
>   __Pyx_WriteUnraisable("test.test");
>   __pyx_L0:;
>   return __pyx_r;
> }
> 
> The intptr_t ctypedef is obviously wrong, but according to the change
> log for Pyrex 0.9.3 [1], this shouldn't matter. So, newer versions of
> Pyrex use the right type for variable declarations, but a wrong type in
> type casting. I'll submit a bug report for it (if I find a bug tracker).

Most actively developed fork of Pyrex named Cython now
hosted at launchpad (:-)

https://bugs.launchpad.net/cython/

And I already sent e-mail to Pyrex ML about cast to intptr_t.

[µ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsG7jzYr338mxwCURArZ6AJ9rEP9ZdnQzV0hMe94PPsOHVeqp0wCgk6EM
TPxBw34Uofb7yssMr9ojxmY=
=ZlYw
-----END PGP SIGNATURE-----