Jump to page: 1 29  
Page
Thread overview
size_t + ptrdiff_t
Feb 19, 2012
Manu
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Manu
Feb 19, 2012
Vladimir Panteleev
Feb 19, 2012
Daniel Murphy
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Manu
Feb 19, 2012
Walter Bright
Feb 21, 2012
Vladimir Panteleev
Feb 19, 2012
Artur Skawina
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Manu
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Manu
Feb 19, 2012
Stewart Gordon
Feb 19, 2012
Manu
Feb 20, 2012
Walter Bright
Feb 20, 2012
Artur Skawina
Feb 20, 2012
Manu
Feb 20, 2012
Walter Bright
Feb 20, 2012
Manu
Feb 20, 2012
Regan Heath
Feb 20, 2012
Kevin Cox
Feb 20, 2012
Walter Bright
Feb 21, 2012
James Miller
Feb 21, 2012
Artur Skawina
Feb 22, 2012
Walter Bright
Feb 22, 2012
Iain Buclaw
Feb 21, 2012
Manu
Feb 22, 2012
Walter Bright
Feb 22, 2012
Stewart Gordon
Feb 20, 2012
Sean Kelly
Feb 20, 2012
Jacob Carlborg
Feb 19, 2012
Timon Gehr
Feb 19, 2012
Manu
Feb 19, 2012
Timon Gehr
Feb 19, 2012
Manu
Feb 20, 2012
Iain Buclaw
Feb 20, 2012
Manu
Feb 20, 2012
Iain Buclaw
Feb 20, 2012
Manu
Feb 20, 2012
Iain Buclaw
Feb 20, 2012
Stewart Gordon
Feb 20, 2012
Johannes Pfau
Feb 21, 2012
Stewart Gordon
Feb 22, 2012
Walter Bright
Feb 22, 2012
Jacob Carlborg
Feb 22, 2012
Stewart Gordon
Feb 22, 2012
Manu
Feb 20, 2012
Jacob Carlborg
Feb 21, 2012
Juan Manuel Cabo
Feb 21, 2012
Iain Buclaw
Feb 21, 2012
Juan Manuel Cabo
Feb 22, 2012
Sean Kelly
Feb 22, 2012
Juan Manuel Cabo
Feb 22, 2012
Juan Manuel Cabo
Feb 22, 2012
Sean Kelly
Feb 22, 2012
Juan Manuel Cabo
Feb 22, 2012
Manu
Feb 22, 2012
Walter Bright
Feb 22, 2012
Jonathan M Davis
Feb 22, 2012
Walter Bright
Feb 22, 2012
Stewart Gordon
Feb 22, 2012
Juan Manuel Cabo
Feb 22, 2012
Juan Manuel Cabo
Feb 22, 2012
Walter Bright
Feb 22, 2012
Don Clugston
Feb 22, 2012
Manu
Feb 20, 2012
Manu
Feb 20, 2012
Johannes Pfau
Feb 20, 2012
Sean Kelly
Feb 20, 2012
Manu
Feb 20, 2012
Sean Kelly
Feb 19, 2012
kennytm
Feb 19, 2012
Manu
Feb 19, 2012
Artur Skawina
Feb 20, 2012
Stewart Gordon
Feb 20, 2012
Artur Skawina
Feb 20, 2012
Stewart Gordon
Feb 20, 2012
Manu
Feb 20, 2012
Artur Skawina
February 19, 2012
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.


February 19, 2012
On 19/02/2012 14:59, 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.

The whole point of size_t and ptrdiff_t is that they are integer types that span the address space.  So that the size of an allocated block of memory (and consequently, the number of elements in an array) is bound to fit in a size_t, and the displacement between two memory locations is bound to fit in a ptrdiff_t.

What would this "register size" type you are proposing be for, exactly?

<snip>
> There is also the problem that there is lots of code written using the incorrect types.
<snip>

Like what?
February 19, 2012
On 19 February 2012 17:09, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> On 19/02/2012 14:59, 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.
>>
>
> The whole point of size_t and ptrdiff_t is that they are integer types that span the address space.  So that the size of an allocated block of memory (and consequently, the number of elements in an array) is bound to fit in a size_t, and the displacement between two memory locations is bound to fit in a ptrdiff_t.
>
> What would this "register size" type you are proposing be for, exactly?
>

You also need a type that knows the native word size of the machine, not just a pointer width. If size_t should be the pointer size, then there needs to be some other type that specifies the register width of the architecture.


> <snip>
>
>  There is also the problem that there is lots of code written using the
>> incorrect types.
>>
> <snip>
>
> Like what?
>

There is code that assumes size_t is the width of the pointer, and other
code that assumes size_t is the width of the native int. Only one of those
is correct, whichever you declare it to be, and another type needs to be
invented to define the other.
It is common that pointers are the same width as the int regs, but there
are many architectures where it's not true.


February 19, 2012
On 19-02-2012 16:26, Manu wrote:
> On 19 February 2012 17:09, Stewart Gordon <smjg_1998@yahoo.com
> <mailto:smjg_1998@yahoo.com>> wrote:
>
>     On 19/02/2012 14:59, 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.
>
>
>     The whole point of size_t and ptrdiff_t is that they are integer
>     types that span the address space.  So that the size of an allocated
>     block of memory (and consequently, the number of elements in an
>     array) is bound to fit in a size_t, and the displacement between two
>     memory locations is bound to fit in a ptrdiff_t.
>
>     What would this "register size" type you are proposing be for, exactly?
>
>
> You also need a type that knows the native word size of the machine, not
> just a pointer width. If size_t should be the pointer size, then there
> needs to be some other type that specifies the register width of the
> architecture.
>
>     <snip>
>
>         There is also the problem that there is lots of code written
>         using the incorrect types.
>
>     <snip>
>
>     Like what?
>
>
> There is code that assumes size_t is the width of the pointer, and other
> code that assumes size_t is the width of the native int. Only one of
> those is correct, whichever you declare it to be, and another type needs
> to be invented to define the other.
> It is common that pointers are the same width as the int regs, but there
> are many architectures where it's not true.

Also, fun fact: Even on x86, pointers aren't necessarily 32- or 64-bit wide - in kernel space. :)

-- 
- Alex
February 19, 2012
On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
> There is code that assumes size_t is the width of the pointer

When is this not true? I can only think of 16-bit far pointers.
February 19, 2012
"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:valucopzdhxdjymkgvuq@forum.dlang.org...
> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>> There is code that assumes size_t is the width of the pointer
>
> When is this not true? I can only think of 16-bit far pointers.

8-bit embedded quite often has 16-bit pointers.


February 19, 2012
On 19 February 2012 18:03, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:

> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>
>> There is code that assumes size_t is the width of the pointer
>>
>
> When is this not true? I can only think of 16-bit far pointers.
>

Ignoring small embedded systems (for which it is almost always true), some that immediately come to mind:

 NaCl (Google Native Client) - x64 arch, 32bit pointers ... <- of immediate
concern to me
 PPC based consoles; PS3, X360, Wii, WiiU (not released yet) - 64bit, all
32bit pointers
 Android, and probably iOS; 64bit ARM chips - will certainly not fork the
OS to use 64bit pointers

word/pointer width mismatch does happen, even if you try to argue it's uncommon, the language MUST be able to express these architectures. It's not an optional fix. Just need to name them properly, and correct existing code.


February 19, 2012
On 19/02/2012 15:26, Manu wrote:
<snip>
> There is code that assumes size_t is the width of the pointer, and other code that assumes
> size_t is the width of the native int.
<snip>

How does it do that?

Indeed, how does code rely on the concept of native int at all?

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

> On 19/02/2012 15:26, Manu wrote:
> <snip>
>
>> There is code that assumes size_t is the width of the pointer, and other
>> code that assumes
>> size_t is the width of the native int.
>>
> <snip>
>
> How does it do that?
>
> Indeed, how does code rely on the concept of native int at all?


You can't imagine any situation where you might want to know how big an int
is?
Anything from calling convention code, structure layout/packing, copying
memory, basically optimising for 64bits at all...
Turn that question around... if you don't know the size of a native int,
how do you propose you take advantage of it?


February 19, 2012
On 19/02/2012 16:07, Daniel Murphy wrote:
> "Vladimir Panteleev"<vladimir@thecybershadow.net>  wrote in message
> news:valucopzdhxdjymkgvuq@forum.dlang.org...
>> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>>> There is code that assumes size_t is the width of the pointer
>>
>> When is this not true? I can only think of 16-bit far pointers.
>
> 8-bit embedded quite often has 16-bit pointers.

And has an 8-bit size_t?

Just found the bit I read before and was trying to find again
http://www.dlang.org/portability.html
"Use size_t as an alias for an unsigned integral type that can span the address space. Array indices should be of type size_t."

Of course, anything below 32-bit is irrelevant to D, but according to cplusplus.com size_t is defined to be the type returned by sizeof.  But where it explains sizeof it doesn't state what type that is, and I don't know what the C or C++ standard says about it.

Stewart.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9