size_t + ptrdiff_t

Manu turkeyman at
Mon Feb 20 03:14:36 PST 2012

On 20 February 2012 10:31, Iain Buclaw <ibuclaw at> wrote:

> On 19 February 2012 18:27, Manu <turkeyman at> wrote:
> > On 19 February 2012 20:07, Timon Gehr <timon.gehr at> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Digitalmars-d mailing list