In my brain "linters" ⊆ "static analyzers".
Anything that looks at code without running it qualifies.
I don't know what you mean by "proper" static analyzer. The static analyzer libraries that I use do produce lint, but this is among many other useful insights.
These are usually linters, not proper static analyzers (although the popular clang-tidy is a bit of both).
A "proper" static analyzer follows control flow and tries to cover all possible variations (and then reporting things like "this pointer here will be null when this other function 10 levels up the callstack is called with parameter "x" having the value "N" - Xcode even gives you a control-flow visualization overlayed as arrows over the source code to give a better idea how the static analyzer arrived at that conclusion).
Running code through a static analyzer takes many times longer than compiling the code.
> They are pretty cool, but give a lot of false positives.
Analyzers usually take assert() as hints (e.g. 'assert(ptr)' hints to the analyzer that ptr isn't expected to be null - so you won't get a "this pointer can potentially be null" false positive. The tighter your assert checks, the fewer false-positives you'll get.