isize_t?

[Manu]

On 23 January 2012 12:55, Don Clugston <dac at nospam.com> wrote:

> On 22/01/12 00:15, Manu wrote:
>
>> On 21 January 2012 22:18, Timon Gehr <timon.gehr at gmx.ch
>> <mailto:timon.gehr at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120123/7de1eef7/attachment.html>