On Mon, Oct 27, 2014 at 4:35 PM, Aaron Ballman <[email protected]> wrote:
> On Mon, Oct 27, 2014 at 7:30 PM, Jordan Rose <[email protected]> > 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 <[email protected]> > 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> > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
