size_t + ptrdiff_t

Walter Bright newshound2 at digitalmars.com
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 thecybershadow.net
> <mailto:vladimir at thecybershadow.net>> 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