Closed Bug 489914 Opened 15 years ago Closed 5 years ago

warn on null callers, warn on no null checks

Categories

(Developer Infrastructure :: Source Code Analysis, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dietrich, Unassigned)

References

Details

in bug 489872, we had a bunch of public entry points not doing null checks, causing crashes b/c of bad callers.

asked taras about using static analysis tools to attack these problems - maybe detecting lack of checks, detecting and warning about potentially bad callers, etc.
Component: Places → Rewriting and Analysis
Product: Toolkit → Core
QA Contact: places → rewriting-and-analysis
maybe dupe of bug 488941?
(In reply to comment #1)
> maybe dupe of bug 488941?

not dupe. That bug deals with explicit not-null changes. This one deals with everything else
It's closely related to bug 488941, right? Hopefully it will be mostly the same code.
Blocks: 489872
(In reply to comment #4)
> It's closely related to bug 488941, right? Hopefully it will be mostly the same
> code.

i'm not so sure. The js one has more flexibility in terms of rewriting the api and limited places need null checking.
 We can't really guarantee nonnullness on public interfaces.
Is the idea here that we should detect API misuse eagerly, using explicit checks, even in release builds, even though that has a performance cost?

This would not buy us much in the JSAPI, because the most common ways to crash JS do not involve unexpectedly-null arguments.  They involve things like forgetting to root a pointer, which our API could not possibly detect.
If by "public entry point" you mean a function called from code dlsym()ed or dynamically linked against, then there's no possible way to statically guarantee that the argument to the "public entry point" is nonnull.  (Well, more precisely, it's not easy.)

OTOH, if you want to guarantee that all Mozilla code satisfies this invariant at the compile time of all Mozilla code, then the machinery in bug 488941 can probably do this for you.  Please let us know if it's insufficient.  (Rewriting existing function parameters to understand non-nullability should be easy; talk to taras or cjones on #static if this is a bottleneck for you.)
Product: Core → Firefox Build System

Coverity and clang have that.

Status: NEW → RESOLVED
Closed: 5 years ago
Priority: -- → P3
Resolution: --- → FIXED
Product: Firefox Build System → Developer Infrastructure
You need to log in before you can comment on or make changes to this bug.