On Sun, Feb 25, 2007 at 09:33:08PM +0100, Frank B. Brokken wrote: > > I don't see any reason why you should use size_t for that instead of > > unsigned int. size_t is intended for use in describing the size of objects > > in memory, not just for anything you know should be non-negative.
> Hm, well, your observation is interesting, but I'm not convinced: > https://www.securecoding.cert.org/confluence/display/seccode/INT01-A.+Use+size_t+for+all+integer+values+representing+the+size+of+an+object > From this: > Any variable that is used to represent the size of an object including, > but not limited to, integer values used as sizes, indices, loop counters, > and lengths should be declared as size_t Er, this is just bad advice. Even on embedded systems, the range of size_t is going to be at least 2^16, and on any of Debian's ports, at least 2^31; if I'm doing that many iterations of anything in a loop, I think my program is in trouble. Using unsigned int is always going to be good enough for a loop counter, and more importantly is going to be more efficient in general: an unsigned int will tend to be optimized for manipulation, a size_t has to support the full addressable memory range. Likewise, the idea of an array of > 2^32 elements, of any size, seems unrealistic, so I can't fathom why anyone would want a size_t index instead of an unsigned int index. Sizes and lengths should absolutely be represented with size_t, yes -- that's exactly what the type exists for. But, as you've recognized, this is all pretty much beside the point. It's still a bug to treat size_t* and int* identically, and that's the bug that should be fixed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
