<div class="gmail_quote">On 20 February 2012 02:48, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com">newshound2@digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2/19/2012 3:15 PM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t<br>
can not be changed (although redefining their meaning would not be a breaking<br>
change, it just might show some cases of inappropriate usages)<br>
I agree that nativeInt should probably be in the standard library, but I'm<br>
really not into that name. It's really long and ugly. That said, I basically<br>
hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs<br>
up those types so much. It's not dependable what they actually mean in C (ie.<br>
ptr size/native word size) on all compilers I've come in contact with :/<br>
</blockquote>
<br></div>
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?<br>
</blockquote></div><br><div>? I must have misunderstood something... I've never seen a 64bit C compiler where 'int' is 64bits.</div>