[Cython] getting rid of C' stlib strcmp() in generated sources

[Robert Bradshaw]

On Mar 6, 2009, at 11:06 PM, Stefan Behnel wrote:

> Lisandro Dalcin wrote:
>> I'm thinking on removing dependencies on the C stdlib...
>> [...]
>> As strcmp() is trivial to implement
>
> Is it really? It does sound trivial, but I would assume that many  
> platforms
> have highly optimised implementations for it. At least, I know that  
> libxml2
> uses memcmp on some platforms and strcmp on others, depending on  
> what's
> known to be faster.

We could wrap it in an #ifndef strcmp

> I wouldn't want to copy this kind of code into Cython,
> just to work around one broken platform.
>
> Honestly, how broken must a platform be to not support strcmp()?

I wouldn't say such a platform is broken, but it would certainly be  
an interesting one. Perhaps embedded devices and the likes.

>> Cython uses it in just a few
>> places, and mainly for work around some deficiencies in the Python
>> C-API, then I what to remove this dependency from Cython generated
>> code.
>
> I have no idea where that's currently used and if those places are  
> in any
> way performance critical, so I can't comment without looking into  
> this. I
> might even have added a couple of those myself.

Most places it's used to (1) verify types on importing, (2) verify C  
api matches, and (3) to verify un-exported types in classmethod and   
cpdef functions, and (4) in keyword parsing code. The first two don't  
need to be fast, the third should be optimized anyways (at least the  
cpdef methods) so I'm going to do that after Lisandro's patch, and  
the last I'm not sure about.

>> IMHO, it is a really good idea to avoid any link-time dependencies in
>> the generated codes... right now, I'm even moved in my own code from
>> using malloc()/free() to use PyMem_Malloc()/PyMem_Free()...
>
> That by itself is perfectly ok and makes sense (although I don't  
> know if
> you can use PyMem_*() in nogil functions/blocks).

I am pretty sure it's not treadsafe.

- Robert