4 days ago
On 17/08/2025 11:21 AM, Ali Çehreli wrote:
> 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

We in fact do reject it.

"When a pointer to T is dereferenced, it must either have a null value, or point to a valid instance of type T."

"Undefined Behavior: dereferencing a pointer that is not null and does not point to a valid instance of type T."

https://dlang.org/spec/type.html#pointers
4 days ago
On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki) Andrew Cattermole 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.
>
> That is not the spec, the book is wrong.

IMHO the book is *not* wrong but rather vague.
What — I think — the book tries to convey is that you can create a zero-length slice outside of the “range” of the original slice.
4 days ago
On Saturday, 16 August 2025 at 23:42:04 UTC, 0xEAB wrote:
> you can create a zero-length slice outside of the “range” of the original slice.

int[] foo = [0, 1, 2];
int[] bar = foo[3 .. $]; // OK
int[] boo = foo[3 .. 4]; // Error: slice [3 .. 4] extends past source array of length 3


4 days ago
On Saturday, 16 August 2025 at 23:32:00 UTC, Richard (Rikki) Andrew Cattermole wrote:
>
> On 17/08/2025 11:21 AM, Ali Çehreli wrote:
>> On 8/16/25 8:44 AM, Brother Bill wrote:
>> 
>>  > [...]
>> past the end of
>>  > [...]
>> 
>> 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
>
> We in fact do reject it.
>
> "When a pointer to T is dereferenced, it must either have a null value, or point to a valid instance of type T."
>
> "Undefined Behavior: dereferencing a pointer that is not null and does not point to a valid instance of type T."
>
> https://dlang.org/spec/type.html#pointers

Op was clear from the beginning that this isn't about dereferencing but mere existence. Doubt any one is confused about dereferencing crash'n.
4 days ago
On Saturday, 16 August 2025 at 23:42:04 UTC, 0xEAB wrote:
> On Saturday, 16 August 2025 at 15:44:45 UTC, Richard (Rikki) Andrew Cattermole 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.
>>
>> That is not the spec, the book is wrong.
>
> IMHO the book is *not* wrong but rather vague.
> What — I think — the book tries to convey is that you can create a zero-length slice outside of the “range” of the original slice.

Separation of concerns:

1. Other than null, is it within spec to have a pointer pointing to invalid memory.
   I believe the answer is yes.
   A pointer can point to any random address, even to memory addresses that don't exist.
   Merely pointing to an invalid address will not produce UB (undefined behavior)
   It would definitely be a "code smell".

2. Is it within spec to dereference a pointer pointing to invalid memory?
   Dereferencing null is not valid.
   Dereferencing a pointer pointing to invalid memory in not valid and can result in UB.
4 days ago
On Sunday, 17 August 2025 at 01:19:41 UTC, Brother Bill wrote:
> Merely pointing to an invalid address will not produce UB (undefined behavior)

I linked you to the gc #wontfix list, it's explicitly the magic words "UB".

Idk what's actually happens(ub isn't a useful distinction), someone would have to extensively test it, but it's expressly not "do whatever" someone must've tried the xor linked list and found it doesn't work in some case.

An invalid pointer outside common use patterns could confuse the GC and some invalid pointers are *known* to confuse the GC(they should've keep the code rather then their wontfix list *tsk*)


4 days ago
On Sunday, 17 August 2025 at 01:44:38 UTC, Monkyyy wrote:
> On Sunday, 17 August 2025 at 01:19:41 UTC, Brother Bill wrote:
>> Merely pointing to an invalid address will not produce UB (undefined behavior)
>
> I linked you to the gc #wontfix list, it's explicitly the magic words "UB".
>
> Idk what's actually happens(ub isn't a useful distinction), someone would have to extensively test it, but it's expressly not "do whatever" someone must've tried the xor linked list and found it doesn't work in some case.
>
> An invalid pointer outside common use patterns could confuse the GC and some invalid pointers are *known* to confuse the GC(they should've keep the code rather then their wontfix list *tsk*)

Understood.  Wild garbage pointers will confuse the GC.
Will a pointer just after a slice confuse the GC, or is the GC expecting this case?
4 days ago
On Sunday, 17 August 2025 at 02:03:53 UTC, Brother Bill wrote:
> On Sunday, 17 August 2025 at 01:44:38 UTC, Monkyyy wrote:
>> On Sunday, 17 August 2025 at 01:19:41 UTC, Brother Bill wrote:
>>> Merely pointing to an invalid address will not produce UB (undefined behavior)
>>
>> I linked you to the gc #wontfix list, it's explicitly the magic words "UB".
>>
>> Idk what's actually happens(ub isn't a useful distinction), someone would have to extensively test it, but it's expressly not "do whatever" someone must've tried the xor linked list and found it doesn't work in some case.
>>
>> An invalid pointer outside common use patterns could confuse the GC and some invalid pointers are *known* to confuse the GC(they should've keep the code rather then their wontfix list *tsk*)
>
> Understood.  Wild garbage pointers will confuse the GC.
> Will a pointer just after a slice confuse the GC, or is the GC expecting this case?

I believe it must be handled by accident(the spec says nothing useful on the topic but ali seems convinced c patterns work), upstream will likely cause a regression for ported code when they pull the trigger on new GC + safe by default and we will see weather the old behavior get codified or if safetyism wins.

But idk, you may have to ask Steve if he tested the new GC on awful c pointer code. 0x or mojo has told me new GC bitshifts data into upper bits( meaning I couldn't, probably shouldn't, brother to learn the actual behavior of the oldgc )

95% of the time, use indexes over pointers, follow that trend.
3 days ago

On Saturday, 16 August 2025 at 22:28:15 UTC, 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, because dereferencing it would result in undefined behavior.

I'm just pondering whether the intention was to accomodate this looping pattern:

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?

I am not sure what "special case" you are referring to, so I will try to explain from first principles.

In C, it is UB to create an out-of-bounds pointer, except for a pointer that is one element past the end of an array, which is allowed. (Source: C11 § 6.5.6 ¶ 8) The intent of this exception is to allow idioms like the one above.

In D, merely creating an out-of-bounds pointer is never UB. In general, D tries to avoid making things UB unless it is absolutely necessary to do so, and that is probably why D is less strict than C here.

In both C and D, it is always UB to dereference an out-of-bounds pointer.

3 days ago

On Sunday, 17 August 2025 at 15:05:32 UTC, Paul Backus wrote:

>

In D, merely creating an out-of-bounds pointer is never UB

The #wontfix list about the gc is labled as ub and is all about pointers(instead of #wontfix and documenting real issues); and this is a fundamental limitation of a gc that scans pointers

Why allyalls safetyphiles ignoring me quote`n the spec. Theres no clarity for any pointer tricks that survive contact with the enemy(the gc) so I dont know what I actaully want to know, but its pretty clearly going to be programmertime expensive to try to find any.