size_t + ptrdiff_t

[Juan Manuel Cabo]

I'm sorry, my snippet is wrong. It's a bit more complicated than what I first
thought, and not even uniform between VC versions:

   "size_t definition and C4267 warning"
   social.msdn.microsoft.com/forums/en-US/vclanguage/thread/62d6df45-e8e4-4bb2-87e2-b3f8e85b4b37

--jm


On 02/21/2012 09:50 PM, Juan Manuel Cabo wrote:
>> size_t is intended to be the C representation.  I very much do not want to end up with a c_size_t.
> 
> Hahah, hold your jaw because it might drop:
> 
> Looking for size_t extravagancies in C, I found that VC uses __int64
> for size_t in x64 target.
> 
> So this behaves differently according to the target:
> 
>        size_t s = -2;
>        if (s < -1) {
>            printf("An supposedly unsigned size_t is less than -1 in x64 ??");
>        } else {
>            printf("all good, size_t is still unsigned");
>        }
> 
> Though I don't ever expect to see a VC backend for D, this shows that
> anything can be expected from C.
> If you want to keep D's size_t unsigned, then let c_size_t do whatever C does,
> and let D use sane types that do what the documentation says.
> 
> :-)
> 
> --jm
> 
> 
> On 02/21/2012 09:10 PM, Sean Kelly wrote:
>> On Feb 21, 2012, at 3:50 PM, Juan Manuel Cabo wrote:
>>
>>>> Eh?
>>>
>>> All the type sizes vary in broken ways in C. The only sane way
>>> to port C structs to D is to use c_<type> that has the size of the
>>> C compiler in the target platform.
>>>
>>> If there is a single C compiler has a different sized size_t
>>> than D's, then one has achieved nothing with the c_int, c_long, etc.
>>>
>>> So that is why it'd be nice, in my opinion, to have c_size_t
>>> (and c_ssize_t) if we are going to have c_int, c_long, etc.
>>
>> size_t is intended to be the C representation.  I very much do not want to end up with a c_size_t.  Are there times when D's size_t would be a different type?  Also, I wonder how much code would break if we eliminated the size_t in object.di and replaced it with Size or whatever.
>