size_t + ptrdiff_t

[Johannes Pfau]

Am Mon, 20 Feb 2012 21:43:31 +0200
schrieb Manu <turkeyman at gmail.com>:

> On 20 February 2012 19:21, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> 
> > On 20 February 2012 16:20, Manu <turkeyman at gmail.com> wrote:
> > > On 20 February 2012 16:03, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> > >>
> > >> On 20 February 2012 11:14, Manu <turkeyman at gmail.com> wrote:
> > >> > On 20 February 2012 10:31, Iain Buclaw <ibuclaw at ubuntu.com>
> > >> > wrote:
> > >> >>
> > >> >> On 19 February 2012 18:27, Manu <turkeyman at gmail.com> wrote:
> > >> >> > On 19 February 2012 20:07, Timon Gehr <timon.gehr at gmx.ch>
> > >> >> > 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.