Menu ▾ ▴

Errors when using external library: Eigen

General Discussion
Clint Chelak
2019-05-30
2019-05-31

  • Clint Chelak

    Clint Chelak - 2019-05-30

    Summary

    When attempting to use cppcheck with the -I command, I get syntax and analysis errors from the Eigen library that we use for our work. I have noted that --config-exclude does not stop cppcheck from looking inside this library and finding errors. Further, including the directories in my suppression file hides found issues, but doesn't prevent cppcheck from returning a non-zero code when it finds an issue of severity error in Eigen.
    I therefore have to create a config file for this, but the process hasn't been too pleasent, so far.

    Error #1

    [include/eigen/src/plugins/CommonCwiseBinaryOps.h:19]: (error) syntax error This macro is throwing an error when included by some files. In particular, it gets caught up on this macro expression: EIGEN_MAKE_CWISE_BINARY_OP(operator-,internal::scalar_difference_op). My attempt to define it was as follows.

    <?xml version="1.0"?>
<def format="2">
  <define name="EIGEN_MAKE_CWISE_BINARY_OP(METHOD, FUNCTOR)" value =""/>
</def>

    I've tried several different approaches for value and different names for METHOD and FUNCTOR (caps and lowercase), but to no avail. It doesn't seem to recognize the macro when running. From what I can tell, it is the symbol following operator. I remove the - in operator- and cppcheck then continues without error, but I quickly get stopped by the second error.

    Error #2

    [include/eigen/src/Core/Redux.h:326]: (error) Analysis failed. If the code is valid then please report this failure. I'm not sure where to begin with this one. The code looks like this, and I'm not sure what to define. Line 326 is the line that begins with EIGEN_STRONG_INLINE.

    template<typename Derived>
template<typename Func>
EIGEN_STRONG_INLINE typename internal::result_of<Func(typename internal::traits<Derived>::Scalar)>::type
DenseBase<Derived>::redux(const Func& func) const
{
typedef typename internal::remove_all<typename Derived::Nested>::type ThisNested;
return internal::redux_impl<Func, ThisNested>
            ::run(derived(), func);
}

    Conclusion

    I'm going to continue to define things inside Eigen in my config file until one day it (hopefully) works, but I wish I could tell cppcheck to simply ignore includes of a certain kind of library altogether. Adding -I and having the code venture down many third-party libraries dramatically increases the time of the checks without much benefit, but it is the only way we have found to check our personal header files without hacking cppcheck with an external script.

    Second, I find it odd that though we suppressed errors in directories such as these, they still affect the status of the return code. Other issues found, such as style or warnings can be suppressed without affecting performance, but error statuses are for some reason special and unalterable in behavior. Currently, with suppressions, we have zero errors of any kind reported in our code, but our CIs are reporting failure from what I can only guess is the suppressed syntax error mentioned above.

    Finally, when an error like this occurs, it appears to stop future checking of the file I was initially interested in. I'd wish to continue on with an assumption that Eigen is ok and needs no checking or review. Is this already possible? If so, what can I do?

    Details

    We run eigen version 3.2.9 with cppcheck version 1.87. Code compiles otherwise, and we've been using Eigen for much longer than we've been using cppcheck, so we know its working (at least in the ways we want it to). My machine, along with most other machines in my company, are running Linux. In this current case, I have Ubuntu 16.04.

     

    Last edit: Clint Chelak 2019-05-30

  • Clint Chelak

    Clint Chelak - 2019-05-30

    A quick solution that wasn't immediately obvious to us was to move all our external libraries to an external directory and updating our include paths accordingly. Previously, we had all header files living in include, both external and not, with corresponding subdirectories to organize it. As a result, doing -I include caused the errors described above. Moving files we want to remain lifted cppcheck's workload and false positives and uncovered many errors that were previously uncaught due to early termination.

    I give special thank you to cppcheck itself for helping us find this solution. As I was looking at cppcheck's source code to see how things were parsed, I noted the externals library, and it sparked the idea.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.