Am Mon, 20 Feb 2012 21:43:31 +0200 schrieb Manu <[email protected]>:
> On 20 February 2012 19:21, Iain Buclaw <[email protected]> wrote: > > > On 20 February 2012 16:20, Manu <[email protected]> wrote: > > > On 20 February 2012 16:03, Iain Buclaw <[email protected]> wrote: > > >> > > >> On 20 February 2012 11:14, Manu <[email protected]> wrote: > > >> > On 20 February 2012 10:31, Iain Buclaw <[email protected]> > > >> > wrote: > > >> >> > > >> >> On 19 February 2012 18:27, Manu <[email protected]> wrote: > > >> >> > On 19 February 2012 20:07, Timon Gehr <[email protected]> > > >> >> > wrote: > > >> >> >> > > >> >> >> On 02/19/2012 03:59 PM, Manu wrote: > > >> >> >>> > > >> >> >>> Okay, so it came up a couple of times, but the questions > > >> >> >>> is, what are > > >> >> >>> we > > >> >> >>> going to do about it? > > >> >> >>> > > >> >> >>> size_t and ptrdiff_t are incomplete, and represent > > >> >> >>> non-complimentary > > >> >> >>> signed/unsigned halves of the requirement. > > >> >> >>> There are TWO types needed, register size, and pointer > > >> >> >>> size. Currently, > > >> >> >>> these are assumed to be the same, which is a false > > >> >> >>> assumption. > > >> >> >>> > > >> >> >>> I propose size_t + ssize_t should both exist, and > > >> >> >>> represent the native > > >> >> >>> integer size. Also something like ptr_t, and ptrdiff_t > > >> >> >>> should > > also > > >> >> >>> exist, and represent the size of the pointer. > > >> >> >>> > > >> >> >>> Personally, I don't like the _t notation at all. It > > >> >> >>> doesn't fit > > the > > >> >> >>> rest > > >> >> >>> of the D types, but it's established, so I don't expect > > >> >> >>> it can change. > > >> >> >>> But we do need the 2 missing types. > > >> >> >>> > > >> >> >>> There is also the problem that there is lots of code > > >> >> >>> written > > using > > >> >> >>> the > > >> >> >>> incorrect types. Some time needs to be taken to correct > > >> >> >>> phobos > > too > > >> >> >>> I > > >> >> >>> guess. > > >> >> >> > > >> >> >> > > >> >> >> 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. > > >> >> > > > >> >> > > > >> >> > 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. > > >> >> > 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. 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. > > >> >> > > > >> >> > 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? > > >> >> > > >> >> gdc offers __builtin_machine_(u)int for word size, and > > >> >> __builtin_pointer_(u)int for pointer size via gcc.builtins > > >> >> module. Nevermind though, it's not quite a "standard" :~) > > >> > > > >> > > > >> > That's beautiful though! Can we alias them, and produce a true > > >> > D type that > > >> > represents them? :) > > >> > > > >> > My basic issue with these size_t/c_int/core.stdc... stuff, is > > >> > that it seems > > >> > the intent is to go out of the way to maintain compatibility > > >> > with C, > > at > > >> > the > > >> > expense of sucking C's messy and poorly defined types into D, > > >> > which > > is a > > >> > shame. It just results in D having the same crappy archaic > > >> > typing problems > > >> > as C. > > >> > I appreciate that the C types should exist for > > >> > interoperability with C (ie, > > >> > their quirks should be preserved for any given > > >> > compiler/architecture), but > > >> > I'd also like to see strictly defined types in D with no > > >> > respect to > > any > > >> > C > > >> > counterpart, guaranteed by the language to be exactly what > > >> > they claim > > to > > >> > be, > > >> > and not confused depending which compiler you try to use. > > >> > > > >> > These 2 GCC intrinsics would appear to be precisely what I was > > >> > looking for > > >> > at the start of this thread... > > >> > > >> > > >> Well, as Walter said, these could be aliased in core.stdc.config. > > > > > > > > > I don't think they are 'standard c' though ;) > > > > OK, I'm just having a trudge through druntime: > > > > intptr_t and uintptr_t are guaranteed to match pointer size. > > > > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stdint.d#cl-70 > > > > c_long and c_ulong are guaranteed to match target long size (here > > would also go c_int and c_uint ;-). > > > > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/config.d#cl-22 > > > > This needs fixing, as wchar_t may not be same size across all > > targets (some change size of wchar_t based on compile time > > switches). > > > > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/stddef.d#cl-28 > > > > This needs fixing, as wint_t may not be same size across all > > targets. > > > > https://bitbucket.org/goshawk/gdc/src/87241c8e754b/d/druntime/core/stdc/wchar_.d#cl-29 > > > > -- > > Iain Buclaw > > > > *(p < e ? p++ : p) = (c & 0x0f) + '0'; > > > > It seems the problem is already MUCH worse than in D already :( .. > this was precisely my fear. > Why all these redundant aliases? Just for C compatibility? That's exactly what those types are for and that's the reason they're in core.stdc.* . Maybe those types shouldn't be used in normal D code, but they are necessary for C bindings.
