Re: Get MD5 without crashing (Mr. Gecko)
Re: Get MD5 without crashing (Mr. Gecko)
- Subject: Re: Get MD5 without crashing (Mr. Gecko)
- From: "Mr. Gecko" <email@hidden>
- Date: Tue, 4 Nov 2008 16:49:32 -0600
I've got it to work.
On Nov 4, 2008, at 1:22 PM, Stuart Malin wrote:
Mr. Gecko,
In your method, because you alloc an instance of a crypto object,
you must release that crypto object. The problem you are having is
that you want to return a value, yet the value is derived from an
object that must be released. In a sense, what you want to do is this:
- (NSString*) md5:(NSString *)MD5
{
SSCrypto *crypto = [[SSCrypto alloc] init];
[crypto setClearTextWithString:MD5];
return [[crypto digest:@"MD5"] hexval];
[crypto release];
}
Which of course *won't* work because the release of the crypto
object will never be executed, and hence you have a memory leak.
Your attempt to add an autorelease shows that you understand this
dilemma, but handled it incorrectly. To use autorelease, you would
do this:
- (NSString*) md5:(NSString *)MD5
{
SSCrypto *crypto = [[[SSCrypto alloc] init] autorelease];
[crypto setClearTextWithString:MD5];
return [[crypto digest:@"MD5"] hexval];
}
In this case, the crypto object will be disposed of sometime later
(when the autorelease pool is emptied).
However, in a strict sense, there is a gotcha lurking here (a
potential problem) because at some unknown time, the crypto object
and the objects that it has created on your behalf will be
deallocated. So, the result returned from this method is risky
because it will, at some time, be deallocated, and the caller of the
md5 method may be holding on to a reference which will then no
longer be valid.
You can use the above autorelease technique so long as you are
absolutely certain the returned result will be used before the
autorelease pool is drained. If you can't guarantee this, or if you
want the reference to survive, then you must handle your memory
management directly. One thing you can do is for the caller of the
method to retain the obtained string, in which case it is
responsible for releasing it when it no longer needs to reference it.
If you want to declaratively release the crypto object, you could
construct and return an autoreleased NSString instance and return
that:
- (NSString*) md5:(NSString *)MD5
{
NSData *digest;
NSString *md5result;
SSCrypto *crypto = [[SSCrypto alloc] init];
[crypto setClearTextWithString:MD5];
digest = [crypto digest:@"MD5"];
md5result = [[NSString stringWithString:[digest hexval]];
[crypto release];
return md5result;
}
Again, the caller of the method must retain the string if it needs
the string to survive iterations of the run loop.
Note: I specifically broke out the digest as an NSData variable for
illustrative purposes -- it does *not* need to be released because
all I have done here is attach a reference to it; it is memory
managed by the crypto object.
Of course, you could create a class method that is a factory that
generates (alloc and init) an NSString object and returns it,
(implicitly retained by the init), in which case the caller of the
factory method is then responsible for releasing it. To do so, you
would be best off making a new class.
HTH.
And do read up on memory management, as suggested by one of the
respondents.
On Nov 4, 2008, at 7:25 AM, Jonathan del Strothe wrote:
Please just refer people to
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
when memory management comes up.
<snip>
On Nov 3, 2008, at 9:05 PM, Mr. Gecko wrote:
Hello I am trying to MD5 a whole bunch of strings and I choose
SSCrypto
for it, but for some reason, it crashes because of memory. I know
it has to
do with releasing, I haven't found much details on when to use
release and
autorelease; so this is a huge task for me to find out.
Here is my method I have made.
- (NSString *)md5:(NSString *)MD5 {
SSCrypto *crypto = [[SSCrypto alloc] init];
[crypto setClearTextWithString:MD5];
return [[[crypto autorelease] digest:@"MD5"] hexval];
}
if you could point out what I am doing wrong, I would be great full.
Thanks,
Mr. Gecko
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden