On 4/11/2024 9:25 AM, Nick Treleaven wrote:
> What I meant was if there is a dereference of a pointer that *may have been* (according to the limited analysis) assigned the address of a local that has gone out of scope, that dereference gets flagged at compile-time. Even though at runtime it may never actually have that address.

Given the following:

```
@safe
void foo()
{
    int* p;
    {
	int x;
	p = &x;
    }
}
```

The compiler gives:

test.d(8): Error: address of variable `x` assigned to `p` with longer lifetime

when the -preview=dip1021 switch is used.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md

Perhaps it's time to make dip1021 the default. Or at least turn it on with dip1000?

On 16.04.24 20:25, Walter Bright wrote:
> ```
> @safe
> void foo()
> {
>      int* p;
>      {
>      int x;
>      p = &x;
>      }
> }
> ```
> 
> The compiler gives:
> 
> test.d(8): Error: address of variable `x` assigned to `p` with longer lifetime
> 
> when the -preview=dip1021 switch is used.
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
> 
> Perhaps it's time to make dip1021 the default. Or at least turn it on with dip1000?
DIP 1021 does nothing here.

It's `-preview=dip1000` that prints the error. `-preview=dip1021` implies `-preview=dip1000`.

And no `-preview` is needed at all for DMD to reject the code (with a different error).

On Wednesday, 17 April 2024 at 00:25:07 UTC, Basile B. wrote:
> On Tuesday, 16 April 2024 at 22:15:42 UTC, ShowMeTheWay wrote:
>>
>> btw. This too is a likely bug:
>>
>> int b;
>> writeln(b);
>>
>> The compiler should require you to assign to 'b' before using it.
>>
>> On the otherhand, this below should *not* get the compilers attention:
>>
>> int b = int.init;
>> writeln(b);
>
> Both are semantically equivalent. The first version is about knowing how the language works, the second is about being stupid. D policy about default initializers is really to create clear poison value. You still have "void initialization" if you want to introduce UBs.
>
> ```d
> int b = void;
> writeln(b);
> ```
>
> that is more what should get the compiler attention.

I don't agree.

Once it's been definitely assigned, the compiler should leave it to the programmer.

If there's a bug, then that is the programmers problem to deal with.

On the otherhand, use of a variable that has not yet been assigned to (regardless of its default value)... well that is almost certainly a bug, and a worthy target for the compilers attention.

Again, C# and Java compilers already do this.

I don't expect to see in the D compiler, given the priorities of D, but it would be nice to have.

On Wednesday, 17 April 2024 at 00:25:07 UTC, Basile B. wrote:
> On Tuesday, 16 April 2024 at 22:15:42 UTC, ShowMeTheWay wrote:
>>
>> btw. This too is a likely bug:
>>
>> int b;
>> writeln(b);
>>
>> The compiler should require you to assign to 'b' before using it.
>>
>> On the otherhand, this below should *not* get the compilers attention:
>>
>> int b = int.init;
>> writeln(b);
>
> Both are semantically equivalent. The first version is about knowing how the language works, the second is about being stupid. D policy about default initializers is really to create clear poison value. You still have "void initialization" if you want to introduce UBs.
>
> ```d
> int b = void;
> writeln(b);
> ```
>
> that is more what should get the compiler attention.

btw. I don't see these as semantically equivalent. The compiler may, but I don't.

int b;
writeln(b);

vs..

int b = void;
writeln(b);

The first one suggests to me a likely bug.

The second one suggest to me, the programmer has definitely assigned a value to b, and whether the writeln code is a bug or not depends on what the programmer intended.... I cannot assume that a bug was not the intention... perhaps it was.. perhaps it wasn't. The compiler would not know the intention of the programmer either.

Only in the case of the 'use of an unassigned variable', can the compiler reasonbly, and quickly, assume it's a likely bug, and that it should alert the programmer.

In the first example, I would want the compiler to alert me.

In the second example, I would want the compiler to get out of the way and let me do what I want...

On 17/04/2024 10:15 AM, ShowMeTheWay wrote:
> Coming from C# or Java, it must feel like coming to D means going backwards with regards to the compilers ability to detect simple bugs like this.

What you are talking about is called type state analysis.

https://en.wikipedia.org/wiki/Typestate_analysis

To do this properly requires a verification data flow analysis.

But once you have that DFA it opens a lot of doors for memory and temporal safety.

Currently D is defined against type state analysis, however it doesn't have it as its own thing.

Pointers are defined to be guaranteed to be non-null when accessed by using the CPU's MMU to throw an exception if you tried to access it.

If you goto past a variable, that is a compiler error as it is not reachable.

My proposal has the hierarchy of:

unreachable < reachable < initialized < default < non-null < user-defined.

https://forum.dlang.org/post/ucdmmlxklanpsggqmwas@forum.dlang.org

So yes D is backwards, because its missing a whole bunch of analysis that you are expecting to exist.

On Tuesday, 16 April 2024 at 18:25:29 UTC, Walter Bright wrote:
> ```
> @safe
> void foo()
> {
>     int* p;
>     {
> 	int x;
> 	p = &x;
>     }
> }
> ```
>
> The compiler gives:
>
> test.d(8): Error: address of variable `x` assigned to `p` with longer lifetime

-dip1000 is good at detecting possible dangling pointers to scope data, but it does it when the pointer is assigned. The difference with the C++ paper is it only tells you *when you try to dereference* a pointer which may point to data which is now invalid because the dereference happens in a higher scope. There are cases where -dip1000 would give a false positive which are still useful that the paper would allow (e.g. involving loops or where the pointer is written to later before the dereference, overwriting the invalid pointer).

Anyway, I was just trying to describe what the C++ paper is supposed to do. My main point was about D detecting uninitialized variable use (which is a prerequisite for non-nullable types).