On Saturday, 16 August 2025 at 15:44:09 UTC, Brother Bill wrote:
> On Saturday, 16 August 2025 at 15:30:43 UTC, H. S. Teoh wrote:
>> On Sat, Aug 16, 2025 at 03:24:55PM +0000, Brother Bill via Digitalmars-d-learn wrote: [...]
>>> So a good D developer should not store an invalid pointer address into a pointer, with the single exception of storing a pointer address just past a slice or array.
>>
>> Where does it say this in the spec?  Because this is wrong.
>>
>> D arrays carry length with them; they do not rely on pointers pointing past the allocated memory region.
>>
>>
>> T
>
> Source: Programming in D book, page 432, chapter 68.8
> Quote: It is valid to point at the imaginary element one past the end of an array.

That's poorly written and unnecessary verbosity, the code block is about slicing with indexes, and that's a logical coniquence of exclusive bounds.

Maybe that was early on in the range v iterator days and he was imagining c++ itorators may matter, they didnt, use ranges and slice quickly.

Maybe the spec and new gc should care, you shouldn't

The gc breaks clever pointers so the pressure to swap to indexes is even higher here. The safetyphiles will talk about bound checks being great ignore them, it's about solving off by one errors once and decreasing the users typing to 1 variable to pass around allowing for semi-tacit

On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/08/2025 3:44 AM, Brother Bill wrote:
>> On Saturday, 16 August 2025 at 15:30:43 UTC, H. S. Teoh wrote:
>>> On Sat, Aug 16, 2025 at 03:24:55PM +0000, Brother Bill via Digitalmars-d-learn wrote: [...]
>>>> So a good D developer should not store an invalid pointer address into a pointer, with the single exception of storing a pointer address just past a slice or array.
>>>
>>> Where does it say this in the spec?  Because this is wrong.
>>>
>>> D arrays carry length with them; they do not rely on pointers pointing past the allocated memory region.
>>>
>>>
>>> T
>> 
>> Source: Programming in D book, page 432, chapter 68.8
>> Quote: It is valid to point at the imaginary element one past the end of an array.
>
> That is not the spec, the book is wrong.


Please provide link to the current spec?

On 17/08/2025 9:26 AM, Brother Bill wrote:
> Please provide link to the current spec?

https://dlang.org/spec/spec.html

On Saturday, 16 August 2025 at 21:26:55 UTC, Brother Bill wrote:
> On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 17/08/2025 3:44 AM, Brother Bill wrote:
>>> On Saturday, 16 August 2025 at 15:30:43 UTC, H. S. Teoh wrote:
>>>> On Sat, Aug 16, 2025 at 03:24:55PM +0000, Brother Bill via Digitalmars-d-learn wrote: [...]
>>>>> So a good D developer should not store an invalid pointer address into a pointer, with the single exception of storing a pointer address just past a slice or array.
>>>>
>>>> Where does it say this in the spec?  Because this is wrong.
>>>>
>>>> D arrays carry length with them; they do not rely on pointers pointing past the allocated memory region.
>>>>
>>>>
>>>> T
>>> 
>>> Source: Programming in D book, page 432, chapter 68.8
>>> Quote: It is valid to point at the imaginary element one past the end of an array.
>>
>> That is not the spec, the book is wrong.
>
>
> Please provide link to the current spec?

Its irrelivent https://dlang.org/spec/type.html#pointers
Its defined on deference not on existence.

Its over in the gc that has any relivence:

https://dlang.org/spec/garbage.html#pointers_and_gc

> Do not xor pointers with other values, like the xor pointer linked list trick used in C.

But this is just whake-a-mole docs, they are just describing how the current gc works without thoery or usecase clarity

Rikki will be wrong, an exclusive bounded would *have to* be defined by an off by 1 pointer, but no one does that not even me.

On 17/08/2025 10:28 AM, Andy Valencia wrote:
> On Saturday, 16 August 2025 at 21:58:30 UTC, Paul Backus wrote:
>> Creating a pointer that points out-of-bounds does not, by itself, result in undefined behavior.
>>
>> However, such a pointer would not be considered a [safe value][1], because dereferencing it *would* result in undefined behavior.
> 
> I'm just pondering whether the intention was to accomodate this looping pattern:
> 
> ```d
> int sum_values(int* p, uint nval) {
>    int result = 0;
>    foreach(_; 0 .. nval) {
>      result += *p++;
>    }
>    return result;
> }
> ```
> 
> A C idiom (I've so very much embraced not using pointers in my D world) which technically leaves "p" pointing beyond the memory range.  Perhaps this is the special case being addressed?
> 
> Andy

All pointer arithmetic is not valid in @safe code.

Arbitrary pointers values become @system, and are not accessible in @safe code. Thanks to @system variables DIP.

It has been addressed.

This isn't just an us thing, other native languages are now going in the direction of disallowing arbitrary pointers. They may only point to valid memory.

If the spec says otherwise, that needs fixing.

On 8/16/25 8:44 AM, Brother Bill wrote:

> Source: Programming in D book, page 432, chapter 68.8
> Quote: It is valid to point at the imaginary element one past the end of
> an array.

I am the author. I have no problem with that part of the book: The quote is correct.

Both C and C++ explicitly state what I wrote above. That guarantee is necessary so that looping over the elements of an array does not make the program illegal just because the array may be sitting at the end of an allocated page.

D does not reject that part of C's memory model.

Ali

On Sat, Aug 16, 2025 at 10:28:15PM +0000, Andy Valencia via Digitalmars-d-learn wrote:
> On Saturday, 16 August 2025 at 21:58:30 UTC, Paul Backus wrote:
> > Creating a pointer that points out-of-bounds does not, by itself, result in undefined behavior.
> > 
> > However, such a pointer would not be considered a [safe value][1], because dereferencing it *would* result in undefined behavior.
> 
> I'm just pondering whether the intention was to accomodate this looping pattern:
> 
> ```d
> int sum_values(int* p, uint nval) {
>   int result = 0;
>   foreach(_; 0 .. nval) {
>     result += *p++;
>   }
>   return result;
> }
> ```
> 
> A C idiom (I've so very much embraced not using pointers in my D world) which technically leaves "p" pointing beyond the memory range. Perhaps this is the special case being addressed?
[...]

Why does it need to be addressed?  D has arrays and slices that know their own length.  From p and nval you can form the slice p[0 .. nval] which lets you iterate safely without risking illegal memory accesses:

	int sum_values(int[] arr) {
		int result = 0;
		foreach (i; arr) {
			result = i;
		}
		return result;
	}


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.