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