On 23 January 2012 12:55, Don Clugston <dac@nospam.com> wrote:
On 22/01/12 00:15, Manu wrote:
On 21 January 2012 22:18, Timon Gehr <timon.gehr@gmx.ch
<mailto:timon.gehr@gmx.ch>> wrote:

   On 01/21/2012 09:06 PM, Alex Rønne Petersen wrote:

       Hi,

       I needed a native-size signed integer type this other day and
       was just
       kinda wondering: Why don't we have this in object.di? isize_t or
       whatever?

       (I have a feeling this has been asked before, but my search-fu
       is weak
       today seemingly...)


   .object.ptrdiff_t


I don't necessarily think ptrdiff_t and signed size_t are the same thing.
Surely size_t should represent the systems native word width? ptrdiff_t
represents the size of a pointer, which is NOT necessarily the same as
the native word width.

Yes. Maybe ptrdiff_t is not even the size of a pointer. Do we guarantee a flat address space?
I mean, back in the old 16 bit segmented architecture days, you could have two 32 bit pointers p and q, and have the difference between them being 16 bits (or an error, if the segments were different).

Maybe similar oddities are possible on the less traditional architectures (Cell, maybe?)

Cell is too weird to worry about (just treat it as 32bit), but it's fairly common to have embedded systems with 64bit processors which retain 32bit pointers because the memory map is fixed, and there's no point. All games consoles, perhaps even phones with the new 64bit ARM processors. Phones don't need >4gb of ram ;) .. Should size_t on this device be 32 or 64bits? The pointers and OS will still be 32bits, I don't see them releasing an Android-64 any time soon.