The C standard guarantees that `size_t` is a type that can hold any array index. This means that, logically, `size_t` should be able to hold any pointer type. I've read on some sites that I found on the Googles that this is legal and/or should always work: void *v = malloc(10); size_t s = (size_t) v;So then in C99, the standard introduced the `intptr_t` and `uintptr_t` types, which are signed and unsigned types guaranteed to be able to hold pointers: uintptr_t p = (size_t) v;So what is the difference between using `size_t` and `uintptr_t`? Both are unsigned, and both should be able to hold any pointer type, so they seem functionally identical. Is there any real compelling reason to use `uintptr_t` (or better yet, a `void *`) rather than a `size_t`, other than clarity? In an opaque structure, where the field will be handled only by internal functions, is there any reason not to do this? By the same token, `ptrdiff_t` has been a signed type capable of holding pointer differences, and therefore capable of holding most any pointer, so how is it distinct from `intptr_t`?Aren't all of these types basically serving trivially different versions of the same function? If not, why? What can't I do with one of them that I can't do with another? If so, why did C99 add two essentially superfluous types to the language?I'm willing to disregard function pointers, as they don't apply to the current problem, but feel free to mention them, as I have a sneaking suspicion they will be central to the "correct" answer.
size_t is defined as an integer type that is the number of elements in an array. Your statement that this can therefore hold a pointer is just plain wrong. A pointer is usually an address and its size may be the same but will be different on some platforms. For example any processor with segmented memory would have a full pointer larger than an offset within a segment. But more powerful is the notion that pointers and size/offsets have different uses and should be defined in ways appropriate to their use. And they are!
