Dereference of Null Pointer

views:

answers:

+1 Q:

Dereference of Null Pointer

+4 A:

It means that self could be made nil by the return value of initWithStyle:reuseIdentifier: and subsequent access to defaults would try to read (hence dereference) at a nil address certainly crashing the app.

David 2010-08-26 16:51:17

Perfect. Thanks!

Jordan 2010-08-26 17:23:47

As a follow-on, what it's indicating is that you should move the code from where the first arrow points up to the end of the method within your first if statement. If that fails, you do not want to proceed with the rest of the initialization, you just want to bail out.

Brad Larson 2010-08-26 17:40:53

Brad, thank you. That's exactly what I did.

Jordan 2010-08-26 17:48:25

I'm a bit uneasy with my answer, because of the fact that objective-c allows messaging to nil. But it has happened to me before to have a crash in those circumstances. I have searched a lot on the subject (of messaging to nil) and there is no references of crashes due to nil access. I guess it is a special case of the constructor ? Or differing runtime implementations ?

David 2010-08-26 18:05:30

I don't quite think it's because the program will crash due to nil access, but rather that it's just not a good idea to dereference nil. Not sure why the analyzer is barking here though. My static analyzer doesn't do that for the same code (though I'm working off the 3.2.3 version), and generally shouldn't bark at nil messaging, since that's an intended aspect of objective-c. Maybe it has more to do with the definition of kDisclosureType? That looks like a #define there, so if Jordan's still around, maybe he could give us that.

David Liu 2010-08-26 19:06:58

It's definitely related to the possible nil returned from the super init. It can be reproduced easily with http://skitch.com/jordanx/duhsr/project

Jordan 2010-08-27 03:57:19

ansaurus

tags:

views:

answers:

Dereference of Null Pointer

related questions