Lisandro Dalcin wrote:
> On Wed, Feb 4, 2009 at 12:37 PM, Dag Sverre Seljebotn
> <[email protected]> wrote:
>>> There are strong objections for my approach? What could be the
>>> potential problems?
>> The objections as I understand them is that not all C compilers
>> understand the "size_t" type. Not all projects (amongst them CPython)
>> adhere to the latest C standards.
>>
>
> And then could you tell me how core CPython could be build with such a
> C compiler...
>
> Please look, at core CPython sources. To be sure, inspect Python-2.3
> sources. They use 'size_t' freely after including "Python.h"
>
>
Well, is Python.h guaranteed to be included in every Cython extension? I
guess it would be. But what about pure C files linked against an
extension for example? People would be required to either include
Python.h for size_t or find it somewhere else in the system. Not that
this is hard, but it will confuse some people :)
I am sure Python 2.3 (and also later releases obviously) defines it
appropriately if it isn't provided by the system. Overall I think this
is a worthwhile change, the new code just ought to be verified on some
of the older known bad compilers.
While poking around I found the following nugget in Sage:
# Memory management
cdef extern from "stdlib.h":
ctypedef unsigned long size_t
So I would expect some buggy code to be exposed by the suggested change
above.
Cheers,
Michael
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
