Pointer dereferenced before the nil check that guards it
ID |
objectivec.correctness.misplaced_nil_check |
Severity |
low |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Null Safety |
Language |
Objective-C |
Description
Reports a pointer dereferenced with → and then, further down the same method, tested against nil or NULL — the guard sits after the access it is meant to protect. Only the → form counts as a dereference: sending a message to nil or reading a property off it is defined behaviour in Objective-C and is not reported. The two statements must belong to the same method; a dereference in one method and a check in the next is not reported. A check written the wrong way round rather than placed wrongly is reported by broken-nil-check.
Rationale
→ on a nil pointer reads or writes through address zero, which crashes the process — and the nil check a few lines below proves the author already believed the pointer could be nil. The order is what makes this expensive to find later: the guard is present, so the code passes review and reads as defensive, and the crash only appears on the input the guard was written for. When the check is a return, the dereference also runs on exactly the path the method was supposed to abandon.
The following code illustrates the pattern detected by this rule:
@implementation Walker
- (void)visit:(struct Node *)node {
// FLAGGED: Pointer dereferenced before the nil check that guards it
node->value = 3;
if (node == nil) {
return;
}
}
- (void)record {
}
- (void)flush {
}
@end