size_t + ptrdiff_t

[Juan Manuel Cabo]

> 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.