On 21 February 2012 01:22, Walter Bright <newshound2@digitalmars.com> wrote:
On 2/20/2012 3:28 AM, Manu wrote:
Even size_t is often
broken in C. I have worked on 64bit systems with 32bit pointers where size_t was
still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this, but maybe my
memory fails me)

I don't know how that could be considered C standard compliant.

I don't know about you, but I very rarely get to work with a C compiler that is 'standards compliant'.. that concept is kinda like a cruel joke in my experience. Does one even exist? :)
I would like to have seen size_t and ptrdiff_t (and friends) also live in core.stdc... and D define and implement its own strictly compliant concepts. As is, any GDC build will have those types defined exactly as in the C compiler... broken or not, and since they're used to interact with C code, it can't be any other way.

I want to be confident when I declare a numeric type that can interact with
pointers, and also when I want the native type.

I think you're probably best off for now by doing your own alias for it.

Fair enough I guess. Consider it though. I really don't want to rely on core.stdc; that idea makes me feel very uneasy, considering how badly C stuffs all this stuff up.
I also don't want to have to import something to access the most basic of types.