Looks like dangling point is not checked even in method mark as safe.
Example:
---
import std.stdio;

class A {
	int value;
	void set_value(int value) @safe {
		this.value = value;
	}
}

void test_safe(A a) @safe {
	a.set_value(1);
}

int main(string[] args) {
	A a = new A();
	test_safe(a);
	test_safe(null);
	test_safe(*(&a+100));
	
	writeln("done.");
	return 0;
}
---
test_safe(null);
and
test_safe(*(&a+100));
will cause segmentation fault.

I guess reason is check dangling pointer is very inefficient.
I found another post about this
http://forum.dlang.org/thread/llezieyytpcbcaoqeajz@forum.dlang.org#post-miyvktgkczatvoguawda:40forum.dlang.org
null pointer is not a safety problem, but pointer like *(&a+100) maybe.

Regard.

On Mon, 14 Apr 2014 19:28:06 -0400, lzzll <ownrepos@gmail.com> wrote:

> Looks like dangling point is not checked even in method mark as safe.
> Example:
> ---
> import std.stdio;
>
> class A {
> 	int value;
> 	void set_value(int value) @safe {
> 		this.value = value;
> 	}
> }
>
> void test_safe(A a) @safe {
> 	a.set_value(1);
> }
>
> int main(string[] args) {
> 	A a = new A();
> 	test_safe(a);
> 	test_safe(null);
> 	test_safe(*(&a+100));
> 	
> 	writeln("done.");
> 	return 0;
> }
> ---
> test_safe(null);
> and
> test_safe(*(&a+100));
> will cause segmentation fault.

Safe cannot verify its inputs. main() is not marked as safe, therefore it will not help.

But even so, dereferencing null is @safe, since it does not corrupt memory. Your *(&a + 100) will definitely not compile if main is marked @safe.

-Steve

On Monday, 14 April 2014 at 23:44:47 UTC, Steven Schveighoffer wrote:
> On Mon, 14 Apr 2014 19:28:06 -0400, lzzll <ownrepos@gmail.com> wrote:
>
>> Looks like dangling point is not checked even in method mark as safe.
>> Example:
>> ---
>> import std.stdio;
>>
>> class A {
>> 	int value;
>> 	void set_value(int value) @safe {
>> 		this.value = value;
>> 	}
>> }
>>
>> void test_safe(A a) @safe {
>> 	a.set_value(1);
>> }
>>
>> int main(string[] args) {
>> 	A a = new A();
>> 	test_safe(a);
>> 	test_safe(null);
>> 	test_safe(*(&a+100));
>> 	
>> 	writeln("done.");
>> 	return 0;
>> }
>> ---
>> test_safe(null);
>> and
>> test_safe(*(&a+100));
>> will cause segmentation fault.
>
> Safe cannot verify its inputs. main() is not marked as safe, therefore it will not help.
>
> But even so, dereferencing null is @safe, since it does not corrupt memory. Your *(&a + 100) will definitely not compile if main is marked @safe.
>
> -Steve

That's correct.
Let me ask:
1. That's mean if I write a safe library and another guy use it in the wrong way, it still not really safe, right?
2. In the real world use, if I received a segmentation fault that mean I had to get the core dump and trace where is the problem, that's all right. But if I not received anything but actually the bad memory has been write or leak, that's the security issue.
3. I hope it will be truly safe in the future, prevent the access to dangling pointer, is there any plan or idea for this?

lzzll:

> 1. That's mean if I write a safe library and another guy use it in the wrong way, it still not really safe, right?

Right.


> 3. I hope it will be truly safe in the future, prevent the access to dangling pointer, is there any plan or idea for this?

How do you suggest to design & implement it?

Bye,
bearophile

On Mon, 14 Apr 2014 21:10:57 -0400, lzzll <ownrepos@gmail.com> wrote:

> Let me ask:
> 1. That's mean if I write a safe library and another guy use it in the wrong way, it still not really safe, right?

Garbage in, garbage out. The safe function must have reasonable expectations, and it's up to you to meet them. Is it "mean"? I don't think so. I think you have to adjust what you think @safe means.

> 2. In the real world use, if I received a segmentation fault that mean I had to get the core dump and trace where is the problem, that's all right. But if I not received anything but actually the bad memory has been write or leak, that's the security issue.

If it's for a null pointer, you will not have a memory corruption.

> 3. I hope it will be truly safe in the future, prevent the access to dangling pointer, is there any plan or idea for this?

This is actually impossible to implement.

-Steve

Let me show some exmaple on c, and two common memory error detect tool.

example 1 (stack overflow):
---
int a = 100;
printf("%p\n", &a);

int *b = &a+1;
printf("%p\n", &b);

*b = 100;
---
valgrind: nothing detected
address sanitizer: ==1996== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffc976dbc4

example 2 (cross address)
---
int a = 100;
int b = 200;
printf("%p\n", &a);
printf("%p\n", &b);

int *c = &a+(&b-&a);
printf("%p\n", c);

*c = 100;
---
Of course it can't be detected.

example 3 (heap overflow)
---
int *a = (int*) malloc(sizeof(int));
printf("%p\n", a);

int *b = a + 1;
printf("%p\n", b);

*b = 100;
---
valgrind: Address 0x51f0044 is 0 bytes after a block of size 4 alloc'd
address sanitizer: AddressSanitizer: heap-buffer-overflow on address 0x60040000dff4

It's possible to a certain extent.
Reference:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.vaddress
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm

I understand implemented this is hard and it need huge cost.
It still be useful if we only use it to detect memory error and trun it off when release.
I'll be glad if I can see it on D after some years.

On 4/14/2014 8:14 PM, lzzll wrote:
> I understand implemented this is hard and it need huge cost.
> It still be useful if we only use it to detect memory error and trun it off when
> release.
> I'll be glad if I can see it on D after some years.

Valgrind is an incredibly useful tool, but programs run terribly slowly under it.

On 4/14/14, 10:47 PM, Walter Bright wrote:
> On 4/14/2014 8:14 PM, lzzll wrote:
>> I understand implemented this is hard and it need huge cost.
>> It still be useful if we only use it to detect memory error and trun
>> it off when
>> release.
>> I'll be glad if I can see it on D after some years.
>
> Valgrind is an incredibly useful tool, but programs run terribly slowly
> under it.

ASAN = like valgrind but a crapton faster. -- Andrei

On Tuesday, 15 April 2014 at 07:09:34 UTC, Andrei Alexandrescu wrote:
> On 4/14/14, 10:47 PM, Walter Bright wrote:
>> On 4/14/2014 8:14 PM, lzzll wrote:
>>> I understand implemented this is hard and it need huge cost.
>>> It still be useful if we only use it to detect memory error and trun
>>> it off when
>>> release.
>>> I'll be glad if I can see it on D after some years.
>>
>> Valgrind is an incredibly useful tool, but programs run terribly slowly
>> under it.
>
> ASAN = like valgrind but a crapton faster. -- Andrei

I think if stuff like this implemented on D will be more faster,
because D have "normal pointer" and "raw pointer",
that mean we only need check them on convert.

example:
A a = new A(); //a is safe
A *b = *a+1; //from normal pointer to raw pointer, no need check
A c = *b; //from raw point to normal point, so check here

But it require the code of D itself is safe, and asan is much low-level.

Walter Bright:

> Valgrind is an incredibly useful tool, but programs run terribly slowly under it.

On the other hand the C/C++ world in the last years has seen
numerous advancements that D should keep an eye on. If you look
at the latest versions of LLVM-Clang and GCC you see various
"sanitizers" (available as built-in tools of the compiler) that
don't use too much memory, don't slow down your code too much,
and catch dangling or wrong pointers, integer overflows,
past-by-one errors, and more. One of those tools is less needed
by D (thanks to the good management of the array bounds), but the
others are nice.

Bye,
bearophile