February 21, 2015 Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think? |
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to FrankLike Attachments: | On Sat, 21 Feb 2015 10:00:06 +0000, FrankLike wrote:
> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
this is wrong.
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to FrankLike | On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Saturday, 21 February 2015 at 18:06:57 UTC, Peter Alexander wrote:
> On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
>> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
>
> It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.
That wouldn't make @nogc safe in any way.
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Saturday, 21 February 2015 at 18:42:54 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 18:06:57 UTC, Peter Alexander wrote:
>> On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
>>> Now,some people think D is a 'Memory safety depends entirely on GC' system Language,what do you think?
>>
>> It's kind of right, at the moment, since @nogc D is still quite difficult to use, mostly due to exceptions and library artifacts. Both of these can be solved though.
>
> That wouldn't make @nogc safe in any way.
@safe @nogc
:-)
(I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
> @safe @nogc
>
> :-)
>
> (I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)
free is an unsafe operation. Unless you don't allocate at all or choose to leak everything, you won't be able to be safe and nogc.
The only way out that I know of is an ownership system.
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Saturday, 21 February 2015 at 20:13:26 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
>> @safe @nogc
>>
>> :-)
>>
>> (I rewrote the post a few times. Originally I just wrote "mark main @safe @nogc and you're fine", but I think it's a bit misleading since @nogc is still difficult to use, so I wrote about that instead and forgot to mention @safe at all. Thanks for pointing out.)
>
> free is an unsafe operation. Unless you don't allocate at all or choose to leak everything, you won't be able to be safe and nogc.
>
> The only way out that I know of is an ownership system.
malloc+free can be trusted if wrapped in something like a ref counted pointer, no?
|
February 21, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On 2/21/15 2:13 PM, Peter Alexander wrote:
> On Saturday, 21 February 2015 at 20:13:26 UTC, deadalnix wrote:
>> On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander wrote:
>>> @safe @nogc
>>>
>>> :-)
>>>
>>> (I rewrote the post a few times. Originally I just wrote "mark main
>>> @safe @nogc and you're fine", but I think it's a bit misleading since
>>> @nogc is still difficult to use, so I wrote about that instead and
>>> forgot to mention @safe at all. Thanks for pointing out.)
>>
>> free is an unsafe operation. Unless you don't allocate at all or
>> choose to leak everything, you won't be able to be safe and nogc.
>>
>> The only way out that I know of is an ownership system.
>
> malloc+free can be trusted if wrapped in something like a ref counted
> pointer, no?
There's more to it, e.g. access to the underlying raw pointer must be carefully restricted. -- Andrei
|
February 22, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On Saturday, 21 February 2015 at 22:13:09 UTC, Peter Alexander wrote:
> malloc+free can be trusted if wrapped in something like a ref counted pointer, no?
Foo bazoom;
class Foo {
void bar() {
bazoom = this;
}
}
void foo() {
RefCounted!Foo f = ...
f.bar();
// bazoom is now a dandling pointer.
}
|
February 22, 2015 Re: Memory safety depends entirely on GC ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Sunday, 22 February 2015 at 04:19:32 UTC, deadalnix wrote:
> On Saturday, 21 February 2015 at 22:13:09 UTC, Peter Alexander wrote:
>> malloc+free can be trusted if wrapped in something like a ref counted pointer, no?
>
> Foo bazoom;
>
> class Foo {
> void bar() {
> bazoom = this;
> }
> }
>
> void foo() {
> RefCounted!Foo f = ...
> f.bar();
>
> // bazoom is now a dandling pointer.
> }
I see, thanks.
Is assigning 'this' from a member function the only problem case?
|
Copyright © 1999-2021 by the D Language Foundation