size_t + ptrdiff_t
turkeyman at gmail.com
Tue Feb 21 00:33:08 PST 2012
On 21 February 2012 01:22, Walter Bright <newshound2 at 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Digitalmars-d