Jump to page: 1 212  
Page
Thread overview
Memory safe in D
Mar 11
Alex
Mar 11
Alex
Mar 11
Alex
Mar 11
Alex
Mar 11
Alex
Mar 12
An Pham
Mar 27
Meta
Mar 11
bachmeier
Mar 11
bachmeier
Mar 11
Sergey
Mar 11
Alex
Mar 11
Sergey
Mar 11
Alex
Mar 12
Alex
Mar 12
Alex
Mar 13
Ogi
Mar 13
Alex
Mar 19
Alex
Mar 13
Alex
Mar 14
Alex
Mar 14
cc
Mar 14
Alex
Mar 19
Alex
Re: Memory safe in D - cppfront/C++
Apr 16
ag0aep6g
Mar 12
cc
Mar 13
Alex
Mar 11
Alex
Mar 11
Ogi
Mar 11
Alex
Apr 16
bachmeier
Apr 16
bachmeier
Apr 17
Basile B.
Apr 17
Doigt
Mar 13
Alex
Mar 13
Alex
Mar 13
Alex
Mar 14
Alex
Mar 16
Don Allen
Mar 21
Don Allen
March 11

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
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

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
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

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
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

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
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

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
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