size_t + ptrdiff_t

[Artur Skawina]

On 02/20/12 01:48, Walter Bright wrote:
> On 2/19/2012 3:15 PM, Manu wrote:
>> Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t
>> can not be changed (although redefining their meaning would not be a breaking
>> change, it just might show some cases of inappropriate usages)
>> I agree that nativeInt should probably be in the standard library, but I'm
>> really not into that name. It's really long and ugly. That said, I basically
>> hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs
>> up those types so much. It's not dependable what they actually mean in C (ie.
>> ptr size/native word size) on all compilers I've come in contact with :/
> 
> I really think that simply adding c_int and c_uint to core.stdc.config will solve the issue. After all, is there any case where the corresponding C int type would be different from a nativeInt?
> 

64bit platforms, depending on the definition of nativeInt.
I'm not sure what it should map to, but 'widestInt' seems to be the result
asked for in this thread. But would that really be different from c_long?

artur