size_t + ptrdiff_t

Iain Buclaw ibuclaw at ubuntu.com
Mon Feb 20 09:21:12 PST 2012


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';


More information about the Digitalmars-d mailing list