size_t + ptrdiff_t

[Manu]

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?

Exactly one identifier for each concept should be nominated and promoted as
'standard' in D, and everyone use that same thing...
The myriad of aliases may still be useful for extern(C) I suppose, but I
think this is a major problem that needs careful consideration.

I think one of the most insidious side effects of this problem is that
programmers don't fully understand what each type is meant to represent
exactly, and they accidentally select the wrong one that just appears to do
the job correctly on their machine/platform at that particular moment. I'm
sure this is the reason behind C compilers messing up the definition of
these themselves types so frequently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120220/421f0598/attachment-0001.html>