View mode: basic / threaded / horizontal-split · Log in · Help
February 19, 2012
size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
"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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Re: size_t + ptrdiff_t
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
Top | Discussion index | About this forum | D home