[MERGE] DirState pyrex helpers

[Jan 'RedBully' Seiffert]

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.


>> [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'?

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 ;)
-- 
Ever notice how fast Windows runs? Neither did I.