<div class="gmail_quote">On 19 February 2012 20:07, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch">timon.gehr@gmx.ch</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 02/19/2012 03:59 PM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Okay, so it came up a couple of times, but the questions is, what are we<br>
going to do about it?<br>
<br>
size_t and ptrdiff_t are incomplete, and represent non-complimentary<br>
signed/unsigned halves of the requirement.<br>
There are TWO types needed, register size, and pointer size. Currently,<br>
these are assumed to be the same, which is a false assumption.<br>
<br></div><div class="im">
I propose size_t + ssize_t should both exist, and represent the native<br>
integer size. Also something like ptr_t, and ptrdiff_t should also<br>
exist, and represent the size of the pointer.<br>
<br>
Personally, I don't like the _t notation at all. It doesn't fit the rest<br>
of the D types, but it's established, so I don't expect it can change.<br>
But we do need the 2 missing types.<br>
<br></div><div class="im">
There is also the problem that there is lots of code written using the<br></div><div class="im">
incorrect types. Some time needs to be taken to correct phobos too I guess.<br>
</div></blockquote>
<br>
Currently, size_t is defined to be what you call ptr_t, ptrdiff_t is present, and what you call size_t/ssize_t does not exist. Under which circumstances is it important to have a distinct type that denotes the register size? What kind of code requires such a type? It is unportable.<br>

</blockquote></div><br><div>It is just as unportable as size_t its self. The reason you need it is to improve portability, otherwise people need to create arbitrary version mess, which will inevitably be incorrect.</div>
<div><div>Anything from calling convention code, structure layout/packing, copying memory, basically optimising for 64bits at all... I can imagine static branches on the width of that type to select different paths.</div>
</div><div>Even just basic efficiency, using 32bit ints on many 64bit machines require extra sign-extend opcodes after every single load... total waste of cpu time.
</div><div><br></div><div>Currently, if you're running a 64bit system with 32bit pointers, there is absolutely nothing that exists at compile time to tell you you're running a 64bit system, or to declare a variable of the machines native type, which you're crazy if you say is not important information. What's the point of a 64bit machine, if you treat it exactly like a 32bit machine in every aspect?</div>