0

With Coverity starting to recognize C++11 noexcept as throw(), it is producing spurious false positives in code calling third-party libraries like Boost. Moreover, some code deliberately intents to crash on exception because the exception in that case is unrecoverable, out-of-contract or bug.

An example Coverity report for this case is:

CID 178772 (#1 of 1): Uncaught exception (UNCAUGHT_EXCEPT)exn_spec_violation: An exception of type boost::exception_detail::clone_impl > is thrown but the throw list throw() doesn't allow it to be thrown. This will cause a call to unexpected() which usually calls terminate().

What is the modelling file to submit to Coverity scan to ignore noexcept globally?

Olzhas Rakhimov
  • 11
  • 5

1 Answers1

0

If you edit the user_nodefs.h file (doesn't exist by default, is referenced by the configs, should exist in the same directory as your coverity_config.xml) you can simply add #define noexcept(x) - this will turn noexcept() into an empty define that will therefore do nothing.

Have you considered using components to exclude third-party defects from your views?

Caleb
  • 1,143
  • 5
  • 13
  • The submission is done via Travis-CI integration, so I am not sure where ``coverity_config.xml`` is located. – Olzhas Rakhimov Apr 26 '17 at 06:52
  • The "defanging" approach is problematic because ``noexcept`` and ``noexcept(...)`` are allowed in the code. How to defang both of them with a single macro? – Olzhas Rakhimov Apr 26 '17 at 07:18
  • That's a bit more difficult (the answer really is the same for any macro question). You could try using a ppp_translator instead - you can specify this to `cov-configure` via `--xml-option`. For example, `cov-configure ... '--xml-option=append_arg:--ppp_translator=replace/noexcept\s*(\(.*\))?/'`. The ppp_translator takes a regex and applies before the pre-processor takes effect (ppp stands for 'pre-pre-process') so you can also use it to massage the code into a form that is more macro-friendly as well. – Caleb Apr 27 '17 at 15:59