[MERGE] DirState pyrex helpers

[John Arbash Meinel]

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

Jan 'RedBully' Seiffert wrote:
> John Arbash Meinel wrote:
>> Jan 'RedBully' Seiffert wrote:
>>> John Arbash Meinel wrote:
>>> [snip snip]
>>>> +
>>>> +
>>>> +cdef extern from *:
>>>> +    ctypedef int size_t
>>>> +
>>>> +
>>>> +
>>> 1) size_t is unsigned
>>> 2) size_t has a platform specific size, you just broke most 64bit archs
>>> is it possible to get it from <stddef.h> or <sys/types.h> or something
>>> like that?
>>> Or maybe i don't understand pyrex.
>> This is mostly just a hint to pyrex for how it should translate python objects
>> into C objects. But yes, I should switch it to unsigned.
>>
>> These definitions are only for the translater, the actual C code uses the C
>> definitions for all structs/typedefs/etc.
>>
> ???
> 
> OK, $DEEP_MAGIC involved :-D
> I still don't understand how this would not break the ABI (the size_t
> getting funktion would expect 64 bit, pyrex delivers 32 bit), but maybe
> it is promoted by the C-compiler from the generated C code.


Because the pyrex code just does:

size_t myvar;

The point is that when you have (in pyrex):

cdef int myfunc(object param):
  size_t size_t_param

  size_t_param = param

When converted to C by the pyrex translater (compiler?)

int myfunc(PyObject *param)
{
  size_t size_t_param;

  size_t_param = PyLongFromInt(param);
}

Pyrex isn't a compiler, it just translates code that looks mostly like
Python into C code, which is then compiled by GCC, etc.

The definitions at the top of pyrex code is just so that the translater
has an idea of what types you are using, and will convert to/from python
for you.

> 
> 
>>> [snip memrchr by repeatly memchr]
>>> is this wise?
>>> Can #ifdef be used with pyrex?
>> I haven't see #ifdef as a possibility.
>>
> As in 'no ifdef in pyrex' or 'don't know what to test for with ifdef'?

AFAIK no ifdef in pyrex.

> 
> hint for the later one:
> #ifdef __GLIBC__
> // pass call to memrchr
> #else
> // fallback code
> #endif
> 
> [snip - code]
>> Thanks, I'll look into incorporating that. On the flip side, we are probably
>> guaranteed that everything is aligned, just because we are using Python strings
>> that were allocated on the heap (and we are always comparing the whole thing).
> Hmmm, yeah, you are right.
> _cmp_path_by_dirblock passes the hole path and only limits the length,
> so ATM this looks mostly sane (packed stringpool anyone?), until someone
> decides to pass a "spliced substring"...
> 
>> But either way, it seems worthwhile to do it 'correctly'.
>>
> Thanks.
> Hopefully the whole align-foo is expressible in pyrex
> (remember, no binary operators on pointer in C (so hand aligning is kind
> of a hack) and the sentence "every pointer fits in an int" is a myth,
> thats what intptr_t was invented for (unfortunately in C99, a little
> late... but many older system have one in <inttypes.h>))
> 
>> John
>> =:->
>>
> Greetings
> 	Jan
> 
> PS: and totally forget in the first mail: Thanks guys for bzr ;)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGl9RRJdeBCYSNAAMRAsb0AKCE2wkDM7j44rAxl6NEhLI9U4nBVwCfc/TY
gOIj1ALuS7AdVciDrQ/0hAg=
=PgXq
-----END PGP SIGNATURE-----