How to "Correctly" Clear Fields in a Class Before Release?

Don Geronimo

New member
Aug 22, 2014
199
0
0
Visit site
I have a class that represents a symmetric key in C#. Is it correct that when an object is released, all it does is it makes the memory used by the object available, but it doesn't actually zero out anything that may have been in memory in the first place, yes? With that assumption, I decided to create a Clear() method that simply writes random data into the fields and properties of the object, with the intention that Clear() should be called somehow to make sure whatever was in memory has been overwritten before its resources are released. However, I'm not sure how exactly that should be done:

  • My first thought was to put Clear(); in the class's destructor, so it would be called to 'clean up' its fields and properties before it is released. However, from what I understand right now, when it's actually collected by the GC is another story.
  • Thus, I researched IDisposable and considered using statements to explicitly define when the object will no longer be used, thus its assets would be overwritten with random bits before being disposed. Apparently, though, the overhead of using IDisposable is potentially expensive.
In my situation, what would be the correct way of moving forward? In theory, after reading, I could use both techniques so that way Clear() would still be called in case I forget to use a 'using' statement.
 

nmercy

New member
Nov 16, 2012
204
0
0
Visit site
That is an interesting question...

A quick look indicates that dispose should be used for unmanaged code to clean it up, free resources, etc... but it sounds like you're using managed code. Also, I don't believe that dispose is called automatically so you would have to call it anyways, at which point you might as well call your clear method whenever you are ready to set an object to null.

It sounds like the destructor is only called when the garbage collector decides to get rid of it. The garbage collector will not get rid of an object that is being used (i.e. something, somewhere still has a reference to it). So once you set an object = null and up until the garbage collector runs the destructor and clears it out, the values would technically still be available in memory if someone could get to that memory.

Your best bet would be to create the Clear() method and call it every time you set the object of that class to null or create a method, I think it could be class static, that takes an object of the class as a parameter, runs the object's clear method, and sets the object to null.

I could also be completely off base as I haven't really had to worry about destructors since C++ days as the garbage collector does a good job of managing memory with default.
 

Don Geronimo

New member
Aug 22, 2014
199
0
0
Visit site
That's essentially where I became stuck on the "right" way of doing it. I am using managed code at the moment, you're correct. I've been reassured by some it's nothing to worry about, but if not for a resource reason, I'd love what fields/properties to be scrubbed at the moment the application was done just to feel like I've done my part in keeping keys out of memory

IDisposable was meant to facilitate cleanup of unmanaged resources in an explicit manner by using 'using' statements. Example usage I've seen:

Code:
 using ( AnObject ThisObject = new AnObject() ) {
/* DO STUFF USING ThisObject */
}


If ThisObject implements IDisposable, Dispose() will run explicitly once the program is done with ThisObject--that is, that block of using is finished. As it's managed, I can't actually control when ThisObject is destroyed, but at least, at the cost of overhead (apparently using is a little expensive) I can make sure that Dispose() is run once the object is explicitly finished in a block of code, with the fallback that Dispose() can be run in the destructor in case I/someone-else forgets to use using.
 

nmercy

New member
Nov 16, 2012
204
0
0
Visit site
If that is what you're most comfortable with using and it works then go with that option :wink:

While programming is a science with rules, it's also an art with a lot of interpretation... so as long as it gets the job done without any harmful side effects it's good.
 

Members online

Forum statistics

Threads
326,649
Messages
2,248,702
Members
428,530
Latest member
Phoquer