Re: Unexpected behaviour with autorelease pool
Re: Unexpected behaviour with autorelease pool
- Subject: Re: Unexpected behaviour with autorelease pool
- From: Filip van der Meeren <email@hidden>
- Date: Mon, 15 Dec 2008 00:14:12 +0100
On 15 Dec 2008, at 00:09, Michael Ash wrote:
On Sun, Dec 14, 2008 at 12:55 PM, Krishna Kotecha
<email@hidden> wrote:
Shouldn't this code be causing an error at some point? And if not,
why not?
Any insights or explanations any one has on this would be
appreciated.
All C programmers (and therefore all Objective-C programmers) must be
familiar with the phrase "undefined behavior".
Simply put, undefined behavior is the term the language spec uses most
of the time when you go off the rails. Accessing a bad pointer is
undefined behavior. Calling printf when the format string doesn't
match the arguments is undefined behavior. Bad memory management is
undefined behavior.
The key thing about undefined behavior is that it is *not* a synonym
for "generates an error message and crashes". Instead, it means that
your system is free to do whatever it wants. Another key phrase here
is "nasal demons". In other words, a conforming compiler could, upon
encountering undefined behavior, cause demons to fly out of your nose.
More likely it will simply crash. But the universe of "undefined
behavior" includes the behavior that you actually want to see! Upon
accessing a bad pointer you may get the value you wanted anyway.
Screwing up your printf arguments might produce the output you were
trying to get. Bad memory management might still work despite the
broken code.
So that's all that's going on here. You're invoking undefined behavior
but still surviving the experience. That's par for the course. It's
one of the things that makes programming in C so "fun": when you screw
up, it's likely that the problem will remain hidden, or will disappear
when you run the debugger, or will only happen on your client's
computer and not on yours.
Lol, I completely agree. And am wondering now why I did not came up
with this, instead of creating autoreleasepool wars with Ken.
Mike
_______________________________________________
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
_______________________________________________
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