Re: Looking for a temporary account on Alpha
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.
vorlon@debian.org http://www.debian.org/
Reply to: