Jump to page: 1 212  
Page
Thread overview
Memory safe in D
Mar 11, 2024
Alex
Mar 11, 2024
Alex
Mar 11, 2024
Alex
Mar 11, 2024
Alex
Mar 11, 2024
Alex
Mar 12, 2024
Walter Bright
Mar 12, 2024
An Pham
Mar 12, 2024
Walter Bright
Apr 12, 2024
ShowMeTheWay
Mar 12, 2024
Walter Bright
Mar 26, 2024
Quirin Schroll
Mar 27, 2024
Meta
Mar 27, 2024
Lance Bachmeier
Mar 30, 2024
Walter Bright
Mar 11, 2024
bachmeier
Mar 11, 2024
bachmeier
Mar 12, 2024
Walter Bright
Mar 12, 2024
Lance Bachmeier
Mar 12, 2024
Walter Bright
Mar 12, 2024
Lance Bachmeier
Mar 12, 2024
Walter Bright
Mar 11, 2024
Sergey
Mar 11, 2024
Alex
Mar 11, 2024
Sergey
Mar 11, 2024
Alex
Mar 12, 2024
Walter Bright
Mar 12, 2024
Alex
Mar 12, 2024
Walter Bright
Mar 12, 2024
Alex
Mar 12, 2024
H. S. Teoh
Mar 13, 2024
Walter Bright
Mar 13, 2024
Ogi
Mar 13, 2024
Alex
Mar 18, 2024
Walter Bright
Mar 19, 2024
Alex
Mar 19, 2024
Alexandru Ermicioi
Mar 30, 2024
Walter Bright
Mar 13, 2024
Walter Bright
Mar 13, 2024
Alex
Mar 13, 2024
Jonathan M Davis
Mar 14, 2024
Alex
Mar 14, 2024
cc
Mar 14, 2024
Alex
Mar 18, 2024
Walter Bright
Mar 19, 2024
Alex
Mar 14, 2024
Nick Treleaven
Mar 18, 2024
Walter Bright
Mar 30, 2024
Walter Bright
Apr 01, 2024
Walter Bright
Mar 22, 2024
Nick Treleaven
Mar 30, 2024
Walter Bright
Mar 30, 2024
Nick Treleaven
Mar 30, 2024
Nick Treleaven
Apr 01, 2024
Walter Bright
Re: Memory safe in D - cppfront/C++
Apr 11, 2024
Nick Treleaven
Apr 11, 2024
Nick Treleaven
Apr 16, 2024
Walter Bright
Apr 16, 2024
ag0aep6g
Apr 18, 2024
Nick Treleaven
Apr 25, 2024
Quirin Schroll
Mar 12, 2024
cc
Mar 13, 2024
Walter Bright
Mar 13, 2024
Alex
Mar 11, 2024
Nick Treleaven
Mar 11, 2024
Alex
Mar 11, 2024
Ogi
Mar 12, 2024
Walter Bright
Mar 11, 2024
Alex
Mar 12, 2024
Walter Bright
Mar 12, 2024
Walter Bright
Mar 12, 2024
Walter Bright
Mar 13, 2024
Walter Bright
Apr 16, 2024
ShowMeTheWay
Apr 16, 2024
bachmeier
Apr 16, 2024
bachmeier
Apr 16, 2024
ShowMeTheWay
Apr 17, 2024
Basile B.
Apr 17, 2024
ShowMeTheWay
Apr 17, 2024
ShowMeTheWay
Apr 17, 2024
Doigt
Mar 13, 2024
Alex
Mar 13, 2024
Alex
Mar 13, 2024
Alex
Mar 14, 2024
Alex
Mar 16, 2024
Don Allen
Mar 18, 2024
Nick Treleaven
Mar 18, 2024
Timon Gehr
Mar 22, 2024
Nick Treleaven
Mar 21, 2024
Don Allen
Mar 18, 2024
Nick Treleaven
March 11, 2024

Hello,

I am interesting D as memory safe language (maybe SafeD?) and have written very simple code:

@safe

import std.stdio;

class A {
	this() {
		writeln("[A] Constructor");
	}

	~this() {
		writeln("[A] Destructor");
	}

	void run() {
		writeln("[A] run");
	}
}

int main()
{
	A a;
	a.run();
	writeln("Hello, world!");
	return 0;
}

Output is:

C:\Software\D\dmd2\windows\bin64\dub.exe run --build-mode separate
    Starting Performing "debug" build using C:\Software\D\dmd2\windows\bin64\dmd.exe for x86_64.
    Building dlang-app ~master: building configuration [application]
     Linking dlang-app
     Running dlang-app.exe
Error Program exited with code -1073741819

Process finished with exit code 2

So I don't see any errors or warnings from compiler when I use uninitialized variable a and don't see any exception with backtrace in runtime (application is build in debug mode).

Is it expected behavior?
Looks like it is not very safe approach and can lead to very unpleasant memory errors...

March 11, 2024
On 11/03/2024 9:16 PM, Alex wrote:
> So I don't see any errors or warnings from compiler when I use uninitialized variable |a| and don't see any exception with backtrace in runtime (application is build in debug mode).
> 
> Is it expected behavior? Looks like it is not very safe approach and can lead to very unpleasant memory errors...

This is expected behavior.

The variable a was default initialized to null.

D has not got type state analysis as part of it, so it cannot detect this situation and cause an error.

It is at the top of my todo list for memory safety research for D, as the IR it requires enables other analysis and provides a framework for it to exist in.
March 11, 2024

On Monday, 11 March 2024 at 08:16:13 UTC, Alex wrote:

>

Hello,
int main()
{
A a;
a.run();
writeln("Hello, world!");
return 0;
}

You need

A a = new A();
March 11, 2024
On Monday, 11 March 2024 at 08:48:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 11/03/2024 9:16 PM, Alex wrote:
>> So I don't see any errors or warnings from compiler when I use uninitialized variable |a| and don't see any exception with backtrace in runtime (application is build in debug mode).
>> 
>> Is it expected behavior? Looks like it is not very safe approach and can lead to very unpleasant memory errors...
>
> This is expected behavior.
>
> The variable a was default initialized to null.
>
> D has not got type state analysis as part of it, so it cannot detect this situation and cause an error.
>
> It is at the top of my todo list for memory safety research for D, as the IR it requires enables other analysis and provides a framework for it to exist in.

Oh... looks like null is also used for refs in D. It's sad :)
I thought it used only for pointers in unsafe mode.
I think, the null safety feature is very important in modern world (maybe "must have" :) ). Very nice to have such feature in D like in Kotlin for example.
So, as I understand, D team have the task in TODO list about implementation something like "null safety"?

March 11, 2024

On Monday, 11 March 2024 at 08:49:35 UTC, Sergey wrote:

>

On Monday, 11 March 2024 at 08:16:13 UTC, Alex wrote:

>

Hello,
int main()
{
A a;
a.run();
writeln("Hello, world!");
return 0;
}

You need

A a = new A();

No. It was test how D handle uninitialized variables.

March 11, 2024
On 11/03/2024 11:20 PM, Alex wrote:
> Oh... looks like null is also used for refs in D. It's sad :)
> I thought it used only for pointers in unsafe mode.
> I think, the null safety feature is very important in modern world (maybe "must have" :) ). Very nice to have such feature in D like in Kotlin for example.
> So, as I understand, D team have the task in TODO list about implementation something like "null safety"?

I'm not sure I'd call myself part of the core D team (although I have another proposal that is currently going through the DIP process that would certainly qualify me for the title!).

However in saying that, memory safety is on the foundation's radar as needing solving.

I'm just the weirdo that is having a go at trying to solve temporal memory safety (an unsolved problem!).
March 11, 2024

On Monday, 11 March 2024 at 10:21:43 UTC, Alex wrote:

>

No. It was test how D handle uninitialized variables.

Oh right. Didn't get from the first read.

Based on the info from here https://en.wikipedia.org/wiki/Void_safety
Only TypeScript, C#/F#, Kotlin, Rust, Swift and Dart have this feature.

March 11, 2024
On Monday, 11 March 2024 at 10:31:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 11/03/2024 11:20 PM, Alex wrote:
>> Oh... looks like null is also used for refs in D. It's sad :)
>> I thought it used only for pointers in unsafe mode.
>> I think, the null safety feature is very important in modern world (maybe "must have" :) ). Very nice to have such feature in D like in Kotlin for example.
>> So, as I understand, D team have the task in TODO list about implementation something like "null safety"?
>
> I'm not sure I'd call myself part of the core D team (although I have another proposal that is currently going through the DIP process that would certainly qualify me for the title!).
>
> However in saying that, memory safety is on the foundation's radar as needing solving.
>
> I'm just the weirdo that is having a go at trying to solve temporal memory safety (an unsolved problem!).

Thank you for the information!
Maybe you know: are there some guys from D foundation here?

Also, I figured out that I can't handle uninitialized access via try/catch:

```d
A a;
try {
    a.run();
} catch(Throwable) {
    writeln("Error");
}
```

So the catch branch not work here.
March 11, 2024

On Monday, 11 March 2024 at 10:35:55 UTC, Sergey wrote:

>

On Monday, 11 March 2024 at 10:21:43 UTC, Alex wrote:

>

No. It was test how D handle uninitialized variables.

Oh right. Didn't get from the first read.

Based on the info from here https://en.wikipedia.org/wiki/Void_safety
Only TypeScript, C#/F#, Kotlin, Rust, Swift and Dart have this feature.

Yes, you right. I had hope what SafeD also support this feature in some way. But looks like not now.

March 11, 2024
On 11/03/2024 11:39 PM, Alex wrote:
> On Monday, 11 March 2024 at 10:31:05 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 11/03/2024 11:20 PM, Alex wrote:
>>> Oh... looks like null is also used for refs in D. It's sad :)
>>> I thought it used only for pointers in unsafe mode.
>>> I think, the null safety feature is very important in modern world (maybe "must have" :) ). Very nice to have such feature in D like in Kotlin for example.
>>> So, as I understand, D team have the task in TODO list about implementation something like "null safety"?
>>
>> I'm not sure I'd call myself part of the core D team (although I have another proposal that is currently going through the DIP process that would certainly qualify me for the title!).
>>
>> However in saying that, memory safety is on the foundation's radar as needing solving.
>>
>> I'm just the weirdo that is having a go at trying to solve temporal memory safety (an unsolved problem!).
> 
> Thank you for the information!
> Maybe you know: are there some guys from D foundation here?

Yes, they are around including Walter, I'm sure he'll see it within the day.

> Also, I figured out that I can't handle uninitialized access via try/catch:
> 
> ```d
> A a;
> try {
>      a.run();
> } catch(Throwable) {
>      writeln("Error");
> }
> ```
> 
> So the catch branch not work here.

The a variable was initialized, via default initialization.

It is in a known state, null.

What you are wanting is a way to have the compiler complain when a nonnull type state is expected, but it is initialized.

D does not support that currently.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11