On 19 February 2012 23:16, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> On 19/02/2012 17:51, Manu wrote:
> <snip>
>
>>    Hang on ... are we talking here about some "native int", or the int
>> type?
>>
> <snip>
>
>  I don't really understand your resistance? I'm going to have the type
>> when I need it, the
>> question is, will it be standardised, or will I (& everyone else) invent
>> the name and
>> introduce a block of (probably not very portable) version() bullshit at
>> the top of their
>> module?
>>
>
> I'm not saying we shouldn't have native integer types in D.  Maybe what's
> needed is to be clearer on what's meant exactly by a native integer type.
>  And then add the types to Phobos/druntime.
>
> I particularly don't understand your suggestion of the names "size_t" and "ssize_t" for these types.  They don't seem to me to denote the size of anything.  I guess "nativeInt" and "nativeUint", defined in whatever module would be suitable, would be one possibility.  Maybe someone has a better idea.
>

well ssize_t is an already established compliment to size_t, I guess it's identical to ptrdiff_t, but some CRT's seem to prefer the ssize_t name. Personally size_t and ssize_t make more sense to me than size_t and ptrdiff_t, which seems like a contradiction of terminology, although the 'ptr' name seems more fitting to what it actually is...

Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t can not be changed (although redefining their meaning would not be a breaking change, it just might show some cases of inappropriate usages) I agree that nativeInt should probably be in the standard library, but I'm really not into that name. It's really long and ugly. That said, I basically hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs up those types so much. It's not dependable what they actually mean in C (ie. ptr size/native word size) on all compilers I've come in contact with :/


> But knowing what code in Phobos/druntime should be using native integer types might help put the problem in better perspective.
>
> Stewart.
>

On 20 February 2012 01:10, kennytm <kennytm@gmail.com> wrote:

> Manu <turkeyman@gmail.com> wrote:
> > I propose size_t + ssize_t should both exist, and represent the native integer size.
>
> sizediff_t (currently just aliased to ptrdiff_t but the link could be
> broken).
>
> > Also something like ptr_t, and ptrdiff_t should also exist, and represent the size of the pointer.
> >
>
> core.stdc.stdint.uintptr_t
>

O_o .. how is this different to size_t now? Why the redundant alias?

On 02/20/12 00:17, Manu wrote:
> On 20 February 2012 01:10, kennytm <kennytm@gmail.com <mailto:kennytm@gmail.com>> wrote:
> 
>     Manu <turkeyman@gmail.com <mailto:turkeyman@gmail.com>> wrote:
>     > I propose size_t + ssize_t should both exist, and represent the native
>     > integer size.
> 
>     sizediff_t (currently just aliased to ptrdiff_t but the link could be
>     broken).
> 
>     > Also something like ptr_t, and ptrdiff_t should also exist,
>     > and represent the size of the pointer.
>     >
> 
>     core.stdc.stdint.uintptr_t
> 
> 
> O_o .. how is this different to size_t now? Why the redundant alias?

C compatibility?
It is redundant in D, at least  until it supports non-flat address spaces. :^)

uintptr_t can hold a pointer, size_t only the size of something. These days there's usually not much difference, but take eg x86_16 segments - you can have several 'views' into memory, that allow for <= size_t-sized objects, but a full 'address' of such an object won't fit into a size_t.

artur

On 2/19/2012 3:15 PM, Manu wrote:
> Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t
> can not be changed (although redefining their meaning would not be a breaking
> change, it just might show some cases of inappropriate usages)
> I agree that nativeInt should probably be in the standard library, but I'm
> really not into that name. It's really long and ugly. That said, I basically
> hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs
> up those types so much. It's not dependable what they actually mean in C (ie.
> ptr size/native word size) on all compilers I've come in contact with :/

I really think that simply adding c_int and c_uint to core.stdc.config will solve the issue. After all, is there any case where the corresponding C int type would be different from a nativeInt?

On 19/02/2012 23:47, Artur Skawina wrote:
> On 02/20/12 00:17, Manu wrote:
<snip>
>>      core.stdc.stdint.uintptr_t
>>
>> O_o .. how is this different to size_t now? Why the redundant alias?
>
> C compatibility?

Why would you want to use meaningless type aliases defined in the C headers in D code?

> It is redundant in D, at least  until it supports non-flat address spaces. :^)
>
> uintptr_t can hold a pointer,
<snip>

Why would you want to do that, as opposed to use one of the pointer types (which is indeed required for GC to work correctly)?

Stewart.

On 02/20/12 01:48, Walter Bright wrote:
> On 2/19/2012 3:15 PM, Manu wrote:
>> Ultimately I don't care, I suspect the prior commitment to size_t and ptrdiff_t
>> can not be changed (although redefining their meaning would not be a breaking
>> change, it just might show some cases of inappropriate usages)
>> I agree that nativeInt should probably be in the standard library, but I'm
>> really not into that name. It's really long and ugly. That said, I basically
>> hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C stuffs
>> up those types so much. It's not dependable what they actually mean in C (ie.
>> ptr size/native word size) on all compilers I've come in contact with :/
> 
> I really think that simply adding c_int and c_uint to core.stdc.config will solve the issue. After all, is there any case where the corresponding C int type would be different from a nativeInt?
> 

64bit platforms, depending on the definition of nativeInt.
I'm not sure what it should map to, but 'widestInt' seems to be the result
asked for in this thread. But would that really be different from c_long?

artur

On 02/20/12 04:21, Stewart Gordon wrote:
> On 19/02/2012 23:47, Artur Skawina wrote:
>> On 02/20/12 00:17, Manu wrote:
> <snip>
>>>      core.stdc.stdint.uintptr_t
>>>
>>> O_o .. how is this different to size_t now? Why the redundant alias?
>>
>> C compatibility?
> 
> Why would you want to use meaningless type aliases defined in the C headers in D code?

C compatibility?


>> uintptr_t can hold a pointer,
> <snip>
> 
> Why would you want to do that, as opposed to use one of the pointer types (which is indeed required for GC to work correctly)?

That's how it can be used in *C*.

And the reason it needs to be exposed to D code is for interoperability with C.


artur

On 19 February 2012 18:27, Manu <turkeyman@gmail.com> wrote:
> On 19 February 2012 20:07, Timon Gehr <timon.gehr@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" :~)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 20 February 2012 02:48, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/19/2012 3:15 PM, Manu wrote:
>
>> Ultimately I don't care, I suspect the prior commitment to size_t and
>> ptrdiff_t
>> can not be changed (although redefining their meaning would not be a
>> breaking
>> change, it just might show some cases of inappropriate usages)
>> I agree that nativeInt should probably be in the standard library, but I'm
>> really not into that name. It's really long and ugly. That said, I
>> basically
>> hate size_t too, it doesn't seem very D-ish, reeks of C mischief... and C
>> stuffs
>> up those types so much. It's not dependable what they actually mean in C
>> (ie.
>> ptr size/native word size) on all compilers I've come in contact with :/
>>
>
> I really think that simply adding c_int and c_uint to core.stdc.config will solve the issue. After all, is there any case where the corresponding C int type would be different from a nativeInt?
>

? I must have misunderstood something... I've never seen a 64bit C compiler where 'int' is 64bits.

On 20 February 2012 10:31, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 19 February 2012 18:27, Manu <turkeyman@gmail.com> wrote:
> > On 19 February 2012 20:07, Timon Gehr <timon.gehr@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...