size_t + ptrdiff_t

Walter Bright newshound2 at
Sun Feb 19 10:52:33 PST 2012

On 2/19/2012 8:23 AM, Manu wrote:
> On 19 February 2012 18:03, Vladimir Panteleev <vladimir at
> <mailto:vladimir at>> wrote:
>     On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>         There is code that assumes size_t is the width of the pointer
>     When is this not true? I can only think of 16-bit far pointers.
> Ignoring small embedded systems (for which it is almost always true), some that
> immediately come to mind:
>   NaCl (Google Native Client) - x64 arch, 32bit pointers ... <- of immediate
> concern to me
>   PPC based consoles; PS3, X360, Wii, WiiU (not released yet) - 64bit, all 32bit
> pointers
>   Android, and probably iOS; 64bit ARM chips - will certainly not fork the OS to
> use 64bit pointers

On these it appears that size_t will be (and should be) the pointer width.

> word/pointer width mismatch does happen, even if you try to argue it's uncommon,
> the language MUST be able to express these architectures. It's not an optional
> fix. Just need to name them properly, and correct existing code.

What I think you're arguing for is a "most efficient" int size, which probably 
would be core.stdc.config.c_int, c_uint.

More information about the Digitalmars-d mailing list