问题
I am integrating Guideline Support Library Checkers into a project of mine.
Microsoft.CppCoreCheck
Microsoft.Gsl
When I run it I get a bunch of errors from included libraries like standard libraries, glm, boost, etc.
One concrete example is SDL.h where I get warnings in sdl_stdinc.h.
I made sure that I include SDL only via one header under my control:
ExtSDL.hpp
#pragma once
#pragma warning(disable: 4710)
#pragma warning(push, 0)
#include <SDL.h>
#pragma warning(pop)
I can not find information on how to exclude this library from the static code analysis.
回答1:
There are multiple ways to suppress CppCoreCheck warnings:
- you can suppress CppCoreChecks either using [[gsl::suppress(chapter)]] attribute, where chapter comes from C++ Core Guidelines, for example, con.4. Please also look at MS docs for information.
- you can use #pragma warning to suppress warnings individually or in bulk, as mentioend above.
- you can suppress all warnings for "not your code" using CAExcludePath.
回答2:
The most practical approach I've found so far is to build up #defines like
#define SDL_WARNINGS 4710 26135
and then #include other people's dirty code thusly
#pragma warning(push)
#pragma warning(disable: SDL_WARNINGS)
#include <SDL.h>
#pragma warning(pop)
That will silence warnings for gsl checkers, based on their associated warning codes e.g C26135 above. It silences the compiler exactly where you want it to keep quiet. Note the warning disablement is local to the push/pop scope.
This sort of approach allows one to compile /Wall /WX even if you turn additional checking on, including gsl. Critically it works even when you have dependencies on other people's headers which aren't warning clean. Sadly this includes every C and C++ standard library implementation I've seen plus Boost, LLVM, the Windows SDK etc. etc. i.e. basically everything. Additionally it protects you from evil headers which alter warning pragmas (some standard library implementations used to do this and may still...) This approach allows you to lift your own code to a higher level of cleanliness and quality than the dross you are dependent upon.
One of the good things about the Microsoft C++ Core Check stuff is the way they've tied it into the usual mechanisms used for warnings, so this approach works uniformly for regular warnings and checkers in extra rulesets. Thank goodness they did something like this: some of the gsl checkers are rather questionable and incompatible with many extant coding styles i.e. turn gsl on for code which #includes big standard vendor library and you rapidly need to construct a long list of warning codes to disable before you can dial the noise down so you can focus on your own code. Of course you can globally #pragma warning(disable: GSL_CHECKERS_YOU_DONT_LIKE) for your own code, so you can focus on the aspects of it you find useful.
Alternatively you can pick the rules to apply by selecting rulesets to use and/or making a custom one. That's presumably going to minimise your build times which aren't as quick with Code Analysis enabled.
It would be nice to have a more direct answer to your question which essentially made the dirty headers build quickly because you could disable checkers for "other people's stuff". It's an obvious feature request but I'm not aware of it being supported. Presumably it would be pretty trivial to implement e.g. only run the checkers on source code found in a specified set of directories, so if a #include steps outside that zone the checkers are automatically disabled. Is anyone at Microsoft reading this?
来源：https://stackoverflow.com/questions/44345855/gslsuppress-whole-include-statements