size_t + ptrdiff_t

[Alex Rønne Petersen]

On 19-02-2012 16:26, Manu wrote:
> On 19 February 2012 17:09, Stewart Gordon <smjg_1998 at yahoo.com
> <mailto:smjg_1998 at yahoo.com>> wrote:
>
>     On 19/02/2012 14:59, Manu wrote:
>
>         Okay, so it came up a couple of times, but the questions is,
>         what are we going to do about it?
>
>         size_t and ptrdiff_t are incomplete, and represent
>         non-complimentary signed/unsigned
>         halves of the requirement.
>         There are TWO types needed, register size, and pointer size.
>         Currently, these are assumed
>         to be the same, which is a false assumption.
>
>
>     The whole point of size_t and ptrdiff_t is that they are integer
>     types that span the address space.  So that the size of an allocated
>     block of memory (and consequently, the number of elements in an
>     array) is bound to fit in a size_t, and the displacement between two
>     memory locations is bound to fit in a ptrdiff_t.
>
>     What would this "register size" type you are proposing be for, exactly?
>
>
> You also need a type that knows the native word size of the machine, not
> just a pointer width. If size_t should be the pointer size, then there
> needs to be some other type that specifies the register width of the
> architecture.
>
>     <snip>
>
>         There is also the problem that there is lots of code written
>         using the incorrect types.
>
>     <snip>
>
>     Like what?
>
>
> There is code that assumes size_t is the width of the pointer, and other
> code that assumes size_t is the width of the native int. Only one of
> those is correct, whichever you declare it to be, and another type needs
> to be invented to define the other.
> It is common that pointers are the same width as the int regs, but there
> are many architectures where it's not true.

Also, fun fact: Even on x86, pointers aren't necessarily 32- or 64-bit 
wide - in kernel space. :)

-- 
- Alex