Lisandro Dalcin wrote: > On Wed, Feb 4, 2009 at 12:58 PM, Michael Abshoff > <[email protected]> wrote: >> Well, is Python.h guaranteed to be included in every Cython extension? >> I guess it would be. >> > > AFAIK, yes. See yourself: > > class ModuleScope(Scope): > .... > def __init__(self, name, parent_module, context): > .... > self.python_include_files = ["Python.h", "structmember.h"]
Good, I don't venture too deeply into the Cython compiler. >> 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 :) >> > > Not sure if I understand you. If pure C file want to use 'size_t', > they are in charge of it. Yes, it was completely dumb to raise the issue here. I needed some sleep and I hope I got caught up on sleep in the last couple hours :) >> 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. >> > > Well, then I'll try to write a patch for all you to review and test. > >> 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. >> > > Well, such a change would expose buggy code and perhaps be backward > incompatible, right? Yes, but code that was buggy and is being exposed by fixing a bug in an upstream tool is acceptable since the developer needs to fix that bug anyway. It might be painful, but the end result is better code. Hadn't I looked around for size_t definitions in Sage we would have hit that bug the first time someone does a 4 GB+ allocation on Windows 64 bit mode once Sage has been ported to MSVC. That is not in the near future, but since I do porting of code all day I can tell you that it is one of the best tools to find bugs in code since all those wrong assumptions in your code come back to bite you in the ass :) Cheers, Michael _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
