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

[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).

[1]
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/CHANGES.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?ISO-8859-1?Q?digit=E1lne?=
	=?ISO-8859-1?Q?_podp=EDsan=E1?= =?UTF-8?Q?_=C4=8Das=C5=A5?=
	=?ISO-8859-1?Q?_spr=E1vy?=
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070801/b5f854bb/attachment.pgp