Leandro Lucarella, el  1 de octubre a las 16:24 me escribiste:
> Walter Bright, el  1 de octubre a las 11:21 me escribiste:
> > I've been interested in having the D compiler take advantage of the flow analysis in the optimizer to do some more checking. Coverity and clang get a lot of positive press about doing this, but any details of exactly *what* they do have been either carefully hidden (in Coverity's case) or undocumented (clang's page on this is blank). All I can find is marketing hype and a lot of vague handwaving.
> 
> Clang is still in development. It will be released with LLVM in the upcoming 2.6 version for the first time. The C and objective C support is supposed to be fairly mature though, but I guess documenting the static analyzer is not very high in their priority list (maybe this will change after the release).
> 
> You can ask in the Clang ML, Clang developers (and LLVM in general) are
> very receptive.

I just found this: http://clang-analyzer.llvm.org/available_checks.html

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El otro día tenía un plan
Pero después me olvidé y me comí un flan

Walter Bright Wrote:

> >> 2. Optimizer collects the info, but ignores this, because people are annoyed by false positives.

clang analyzer tries to avoid false positives very hard. To the point that every error message has link for sending a bug report.

> The problem crops up when there are two connected variables:
> 
>    void foo(bool flag)
>    {
>      char* p = null;
>      if (flag)
> 	p = "hello";
>      ...
>      if (flag)
> 	bar(*p);
>    }
> 
> The code is logically correct, there is no null pointer dereference possible. However, the data flow analysis will see the *p and see two reaching definitions for p: null and "hello", even though only one actually reaches.
> 
> Hence the false positive. To eliminate the false error report, the user would have to insert a redundant null check.
> 
> Does this happen in practice? Yes.

I've tested this exact code in clang analyzer and it's actually smart enough no to report that as error!

 if (flag)
        bar(*p)

is not reported, but:

 if (!flag)
        bar(*p)

is reported, so the analyzer can follow connected variables properly.