Re: Looking for a temporary account on Alpha

["Frank B. Brokken" <f.b.brokken@rug.nl>]

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