On Feb 6, 2009, at 2:52 PM, Michael Abshoff wrote: > Carl Witty wrote: >> On Fri, Feb 6, 2009 at 1:59 PM, Robert Bradshaw > > <SNIP> > >>> I think "int" is the best thing to return--it can always get coerced >>> up to a size_t if needed, but the other way may prove problematic. >>> Also, "int" is a more abstract (conceptually at least) type (better >>> fitting with the ambiguity in the C standard), and we shouldn't have >>> to worry about overflow in this case. >> >> Certainly the result of sizeof can overflow an int. (Presumably on >> 64-bit Windows, it can overflow unsigned long, as well.) >> >> Or are you saying that we don't have to worry about it because people >> won't define such large types?
That is what I was implying. But it isn't valid in retrospect because one might do, say, malloc(sizeof(T) * 4000000000) >> That may be true in practice, but it >> makes me uncomfortable. > > +1 > > There *is* actually code in the Sage library that has overflow > potential > on 64 bit Windows and it needs to be fixed. Debugging some strange > segfault caused by the above is hard enough at it is, adding platform > specific issues doesn't make it any better. > > The C and C++ people did define size_t for a reason since all those > assumptions about int or long being "big enough" does not hold true in > the real world, so let's do this by the book. I hadn't yet read the rest of this thread where it looks like Python.h assumes (or defines?) size_t. Given that's the case, I'm very much in favor of making it native to Cython and the sizeof return type. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
