[PATCH] Static analysis checker for catch handler inversion

[Richard Smith]

On Mon, Oct 27, 2014 at 4:35 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Mon, Oct 27, 2014 at 7:30 PM, Jordan Rose <jordan_rose at apple.com>
> wrote:
> > Nifty! But do you think this is cheap enough for a general compiler
> warning? It certainly doesn't depend on the analyzer's path-sensitive
> analysis, so it's mostly just how much we care about the cost of
> isDerivedFrom.
>
> This should be relatively inexpensive, so it may make sense as a
> general compiler warning if others feel that's a better approach.
>

Yes, I think this is a good candidate for an (on-by-default) compiler
warning.


> Thanks!
>
> ~Aaron
> >
> > Jordan
> >
> >
> >> On Oct 27, 2014, at 15:30, Aaron Ballman <aaron at aaronballman.com>
> wrote:
> >>
> >> It is possible to write catch handlers such that they never execute
> >> due to inversion of the class hierarchy, such as:
> >>
> >> class B {};
> >> class D : public B {};
> >>
> >> void f() {
> >>  try {
> >>    // ...
> >>  } catch (B &b) {
> >>    // ...
> >>  } catch (D &d) {
> >>    // ...
> >>  }
> >> }
> >>
> >> This patch causes a static analysis warning to be generated for code
> >> where a catch handler cannot execute due to class hierarchy inversion
> >> with regards to other catch handlers for the same try block.
> >>
> >> This issue is covered by CERT's secure coding rule:
> >>
> https://www.securecoding.cert.org/confluence/display/cplusplus/ERR36-CPP.+Catch+handlers+should+order+their+parameter+types+from+most+derived+to+least+derived
> >>
> >> It's also covered by MISRA rule 15-3-6.
> >>
> >> ~Aaron
> >> <CatchHandlerChecker.patch>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141027/ab58ef28/attachment.html>