On 2/19/2012 8:23 AM, Manu wrote:
On 19 February 2012 18:03, Vladimir Panteleev <vladi...@thecybershadow.net <mailto:vladi...@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.
