<div class="gmail_quote">On 20 February 2012 16:03, Iain Buclaw <span dir="ltr"><<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.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="HOEnZb"><div class="h5">On 20 February 2012 11:14, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
> On 20 February 2012 10:31, Iain Buclaw <<a href="mailto:ibuclaw@ubuntu.com">ibuclaw@ubuntu.com</a>> wrote:<br>
>><br>
>> On 19 February 2012 18:27, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>
>> > On 19 February 2012 20:07, Timon Gehr <<a href="mailto:timon.gehr@gmx.ch">timon.gehr@gmx.ch</a>> wrote:<br>
>> >><br>
>> >> On 02/19/2012 03:59 PM, Manu wrote:<br>
>> >>><br>
>> >>> Okay, so it came up a couple of times, but the questions is, what are<br>
>> >>> 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.<br>
>> >>> Currently,<br>
>> >>> these are assumed to be the same, which is a false assumption.<br>
>> >>><br>
>> >>> 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<br>
>> >>> 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>
>> >>> There is also the problem that there is lots of code written using the<br>
>> >>> incorrect types. Some time needs to be taken to correct phobos too I<br>
>> >>> guess.<br>
>> >><br>
>> >><br>
>> >> Currently, size_t is defined to be what you call ptr_t, ptrdiff_t is<br>
>> >> present, and what you call size_t/ssize_t does not exist. Under which<br>
>> >> circumstances is it important to have a distinct type that denotes the<br>
>> >> register size? What kind of code requires such a type? It is<br>
>> >> unportable.<br>
>> ><br>
>> ><br>
>> > It is just as unportable as size_t its self. The reason you need it is<br>
>> > to<br>
>> > improve portability, otherwise people need to create arbitrary version<br>
>> > mess,<br>
>> > which will inevitably be incorrect.<br>
>> > Anything from calling convention code, structure layout/packing, copying<br>
>> > memory, basically optimising for 64bits at all... I can imagine static<br>
>> > branches on the width of that type to select different paths.<br>
>> > Even just basic efficiency, using 32bit ints on many 64bit machines<br>
>> > require<br>
>> > extra sign-extend opcodes after every single load... total waste of cpu<br>
>> > time.<br>
>> ><br>
>> > Currently, if you're running a 64bit system with 32bit pointers, there<br>
>> > is<br>
>> > absolutely nothing that exists at compile time to tell you you're<br>
>> > running a<br>
>> > 64bit system, or to declare a variable of the machines native type,<br>
>> > which<br>
>> > you're crazy if you say is not important information. What's the point<br>
>> > of a<br>
>> > 64bit machine, if you treat it exactly like a 32bit machine in every<br>
>> > aspect?<br>
>><br>
>> gdc offers __builtin_machine_(u)int for word size, and<br>
>> __builtin_pointer_(u)int for pointer size via gcc.builtins module.<br>
>> Nevermind though, it's not quite a "standard" :~)<br>
><br>
><br>
> That's beautiful though! Can we alias them, and produce a true D type that<br>
> represents them? :)<br>
><br>
> My basic issue with these size_t/c_int/core.stdc... stuff, is that it seems<br>
> the intent is to go out of the way to maintain compatibility with C, at the<br>
> expense of sucking C's messy and poorly defined types into D, which is a<br>
> shame. It just results in D having the same crappy archaic typing problems<br>
> as C.<br>
> I appreciate that the C types should exist for interoperability with C (ie,<br>
> their quirks should be preserved for any given compiler/architecture), but<br>
> I'd also like to see strictly defined types in D with no respect to any C<br>
> counterpart, guaranteed by the language to be exactly what they claim to be,<br>
> and not confused depending which compiler you try to use.<br>
><br>
> These 2 GCC intrinsics would appear to be precisely what I was looking for<br>
> at the start of this thread...<br>
<br>
<br>
</div></div>Well, as Walter said, these could be aliased in core.stdc.config.<br></blockquote><div><br></div><div>I don't think they are 'standard c' though ;)</div></div>