www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is "delete" unsafe?

reply "Minas" <minas_mina1990 hotmail.co.uk> writes:
So the delete keyword has been deprecated - so good bye manual 
memory management...

I have read in some threads that delete is an unsafe operation. 
What does this exactly mean? What is unsafe about it? What does 
it have to do with the GC? (if there was no garbage collection, 
would it be unsafe?)
Oct 26 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 26 October 2012 at 23:03:15 UTC, Minas wrote:

 What is unsafe about it?


If you delete something but keep a reference to it, at some point 
down the line, the memory could be reused.

Then your old reference points to a different type of object and 
could treat it differently.


Just for example:

string code = something;

delete code;

// but oops code is still there and pointing at some memory...

int[] something = new int(10); // this might reuse the memory


eval(code); // now this evals a bunch of ints as if they were 
code which certainly isn't what you expected
Oct 26 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 27-10-2012 01:03, Minas wrote:

 So the delete keyword has been deprecated - so good bye manual memory
 management...


Um, no. Use destroy() from the object module instead. To free memory 
from the GC, use core.memory.GC.free().


 I have read in some threads that delete is an unsafe operation. What
 does this exactly mean? What is unsafe about it? What does it have to do
 with the GC? (if there was no garbage collection, would it be unsafe?)


void* p = malloc(__traits(classInstanceSize, Object));
p[0 .. __traits(classInstanceSize, Object)] = typeid(Object).init[];
Object o = cast(Object)p;
delete o; // Spot the bug.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Oct 26 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, October 27, 2012 01:09:39 Alex Rønne Petersen wrote:

 On 27-10-2012 01:03, Minas wrote:

 So the delete keyword has been deprecated - so good bye manual memory
 management...


 
 Um, no. Use destroy() from the object module instead.


Definitely, though it's important to note that what it's doing is inherently 
different. It destroys what you pass to it but does _not_ free the memory, 
which is why it's safer.


 To free memory
 from the GC, use core.memory.GC.free().


Yes. But using core.memory.GC.free is unsafe for the same reasons that delete 
is. It's just that it's a druntime function instead of a part of the language, 
so it's less likely for someone to free GC memory without knowing what they're 
doing. It's there because there _are_ times when it makes sense and is useful, 
but it's definitely not safe, so you have to be careful and know what you're 
doing.

- Jonathan M Davis
Oct 26 2012
parent reply mw <mingwu gmail.com> writes:
On Saturday, 27 October 2012 at 01:08:12 UTC, Jonathan M Davis 
wrote:

 On Saturday, October 27, 2012 01:09:39 Alex Rønne Petersen 
 wrote:

 On 27-10-2012 01:03, Minas wrote:

 So the delete keyword has been deprecated - so good bye 
 manual memory management...


 
 Um, no. Use destroy() from the object module instead.


 Definitely, though it's important to note that what it's doing 
 is inherently different. It destroys what you pass to it but 
 does _not_ free the memory, which is why it's safer.


 To free memory
 from the GC, use core.memory.GC.free().


 Yes. But using core.memory.GC.free is unsafe for the same 
 reasons that delete is. It's just that it's a druntime function 
 instead of a part of the language, so it's less likely for 
 someone to free GC memory without knowing what they're doing. 
 It's there because there _are_ times when it makes sense and is 
 useful, but it's definitely not safe, so you have to be careful 
 and know what you're doing.


What do you mean by saying "it's definitely not safe" here?

I mean: if I'm careful and know what I'm doing, e.g. remove all 
the reference to  any part of the `object` before call 
core.memory.GC.free(object), is there still any inherit "unsafe" 
side of `free` I should be aware of?

FYI: I just described my use case here:

https://forum.dlang.org/post/hzryuifoixwwywwifwbz forum.dlang.org
Sep 22 2020
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote:

 It's there because there _are_ times when it makes sense and 
 is useful, but it's definitely not safe, so you have to be 
 careful and know what you're doing.


 What do you mean by saying "it's definitely not safe" here?

 I mean: if I'm careful and know what I'm doing, e.g. remove all 
 the reference to  any part of the `object` before call 
 core.memory.GC.free(object), is there still any inherit 
 "unsafe" side of `free` I should be aware of?

 FYI: I just described my use case here:

 https://forum.dlang.org/post/hzryuifoixwwywwifwbz forum.dlang.org


If there are no lingering references, the function calling free() 
can safely be made  trusted.

--
   Simen
Sep 22 2020
prev sibling next sibling parent Elronnd <elronnd elronnd.net> writes:
On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote:

 What do you mean by saying "it's definitely not safe" here?

 I mean: if I'm careful and know what I'm doing, e.g. remove all 
 the reference to  any part of the `object` before call 
 core.memory.GC.free(object), is there still any inherit 
 "unsafe" side of `free` I should be aware of?


'"delete" is unsafe' doesn't mean 'any program which uses 
"delete" is unsafe'.  What it means is, in a language that has 
'delete', /some/ programs will be unsafe.  If your language has 
delete, you cannot guarantee that programs will be safe.

Now, D is not safe by default ('delete' would definitely be 
disallowed in  safe code), but it still wants to have features 
that /encourage/ safety (fat pointers are a great example of 
this).

'delete' and 'free' are both equally unsafe; however, if you have 
verified that your usage of them is safe, it is fine to use them.
Sep 23 2020
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 23 September 2020 at 04:15:51 UTC, mw wrote:

 On Saturday, 27 October 2012 at 01:08:12 UTC, Jonathan M Davis 
 wrote:

 Yes. But using core.memory.GC.free is unsafe for the same 
 reasons that delete is. It's just that it's a druntime 
 function instead of a part of the language, so it's less 
 likely for someone to free GC memory without knowing what 
 they're doing. It's there because there _are_ times when it 
 makes sense and is useful, but it's definitely not safe, so 
 you have to be careful and know what you're doing.


 What do you mean by saying "it's definitely not safe" here?

 I mean: if I'm careful and know what I'm doing, e.g. remove all 
 the reference to  any part of the `object` before call 
 core.memory.GC.free(object), is there still any inherit 
 "unsafe" side of `free` I should be aware of?

 FYI: I just described my use case here:

 https://forum.dlang.org/post/hzryuifoixwwywwifwbz forum.dlang.org


The logic is:  safe code isn't allowed to have access to dangling 
pointers, because you're allowed to dereference pointers in  safe 
code, and dereferencing a dangling pointer is undefined behavior. 
Since manually freeing memory can create dangling pointers, 
you're not allowed to do it in  safe code.

If you can prove with 100% certainty that you're not going to 
create a dangling pointer, you can wrap the call to `free` in a 
 trusted lambda:

     ()  trusted { free(ptr); ptr = null; }();
Sep 23 2020
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Oct 27, 2012 at 01:03:14AM +0200, Minas wrote:

 So the delete keyword has been deprecated - so good bye manual
 memory management...


Um, that's a misconception. If you want manual memory management, use
malloc(), free(), and emplace.



 I have read in some threads that delete is an unsafe operation. What
 does this exactly mean? What is unsafe about it? What does it have
 to do with the GC? (if there was no garbage collection, would it be
 unsafe?)


The problem is that you can call delete on GC'd objects, which in some
cases causes bad interaction with the GC. That's why it has been
deprecated.

The intention was never to get rid of manual memory management. It was
to prevent unsafe interactions with the GC. If you don't want to use the
GC, use malloc(), free(), and emplace. (In fact, this way you can have
*both* GC and manual memory management. The emplace()'d objects will be
manually managed, and the others will be collected by the GC.)


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Oct 26 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, October 26, 2012 16:12:15 H. S. Teoh wrote:

 The problem is that you can call delete on GC'd objects, which in some
 cases causes bad interaction with the GC. That's why it has been
 deprecated.
 
 The intention was never to get rid of manual memory management. It was
 to prevent unsafe interactions with the GC. If you don't want to use the
 GC, use malloc(), free(), and emplace. (In fact, this way you can have
 *both* GC and manual memory management. The emplace()'d objects will be
 manually managed, and the others will be collected by the GC.)


Exactly. In general, you should do manual memory management with memory that 
is manually allocated and _not_ with memory which is GC-allocated (which is 
where delete goes wrong).

- Jonathan M Davis
Oct 26 2012