Dear Steve Langasek, you wrote: > > The intention here is to use size_t in situations where the value is known > > to be non-negative. > > 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 One could start a word game here and point out that it doesn't explicitly state that size_t should be used for non-negative values, but the above sentence does explicitly mention `not limited to'. Since the examples given are definitely not limited to `sizes of objects in memory', but rather have non-negativeness in common, I still consider my position to be correct. Another interesting one: Rationale for International Standard?Programming Languages?C Revision 5.10. April 2003.: >From that (quotes by me): 6.5.3.4 ... The type of sizeof, whatever it is, is published (in the library header <stddef.h>) as size_t, since `it is useful for the programmer to be able to refer to this type.' This requirement implicitly `restricts size_t to be a synonym for an existing unsigned integer type.' ... Thus size_t is also a `convenient type for array sizes', and is so used in several library functions. So, it's considered a `convenient type' for array sizes; which doesn't state that it is restricted to that. It does, however, explicitly state that it's a synonym of an unsigned integer type. Finally, I have this one, providing the `philosophical rationale' for using size_t (at least to me it does): http://www.cprogramming.com/tutorial/typedef.html Typedefs and Abstraction Typedefs provide a level of abstraction away from the actual types being used, allowing you, the programmer, to focus more on the concept of just what a variable should mean. This makes it easier to write clean code, but it also makes it far easier to modify your code. For instance, if if you decided you really needed to support sizes that were too big to store in an unsigned int, you could make a change in one place in your code--the typedef itself--to make size_t equivalent to, for instance, an unsigned long. Almost none of your code would need to change! But in the end I'm confronted with an error in my program, which I now feel I can solve thanks to the observation that a size_t * can't always be considered an unsigned int *. The subtlety is, I think, that although the above revision 5.10 states that size_t is synonym to an unsigned integer type, it doesn't state that it's a synonym of an `unsigned int'. Could very wel be an `unsigned long int'. Thus I stumbled over a big endian :-) Thanks for the discussion! -- Frank B. Brokken Computing Center, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
