|
Greg Utas wrote: The only tweak was that it wants x86 or x64 for the platform instead of Win32 or Win64.
That'll be something that's changed since VS2013 - I snuck the msbuild command-line out of a build script we use on a project built with VS2013.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hmm, that was a direct MSBuild, but it wants you to build via its own tool, which is configured for gcc with no sign of the instructions for how to change this...
|
|
|
|
|
Hmmm - that's odd - I've got cov-build to work for me, admittedly with a Visual Studio solution autogenerated by CMake.
Anyway - try running this command... I ran it, thinking it would allow me to tweak my MSVC configuration & maybe it changed my default config, or enabled msvc?
cov-configure --msvc
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
It appears to be doing a compile through cov-build now, thanks.
|
|
|
|
|
384 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully. Thanks for your help! Now I have to worry about what they'll find. 
|
|
|
|
|
I've uploaded my (very minimal) code & have to confess I'm perplexed at some of the 'defects' Coverity raises:
- Apparently, this line of code raises an exception (which isn't caught in
main, as I don't use a global exception handler).
std::wostringstream oss;
Trouble is... that statement doesn't raise an exception... I've looked at the source code for wostringstream (and the associated classes), and while an exception can be raised if the stream's state is set to 'bad' or 'fail', the code path that Coverity is complaining about is setting the stream state to 'good', using a static constexpr value (goodbit, as seen here). Maybe Coverity doesn't understand what constexpr means? - This one is fair enough (although slightly trivial?) - Coverity moans at me for using
std::hex to change the default base output by a std::ostream and not restoring the old format. That's one of the reasons I prefer using libfmt (soon to be part of C++20 - yay!) rather than plain old iostreams...
I've used clang-tidy a lot, as well as the static analyzer built into clang, and they haven't raised false positives like this...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I am familiar with the full, commercial Coverity with a local database; there may be differences from the cloud solution.
You have a lot of settings, e.g. the "agressiveness" level. If you set it to maximum, you certainly get a share of false warnings (and the documententation clearly warns about this). I rarely catch any non-false warnings by running at max agressivness.
Also, you can select an arbitrary set of checkers to be run, and many of them can be configured, checker by checker. When you triage the issue in the database, you may flag it as false warning, and you will not be see any more of that issue. It may take some effort tuning the options to your preferences and environment, to give you only those reports that you wish; it isn't perfectly configured out of the box.
Disclaimer: I have used coverity with plain C and with C#, not with C++.
With C# I have insisted for weeks in a row that some of the issues are false warnings, until I learn something new and realize that Coverity was right after all! (This is mostly resource leak issues, but also exception issues.)
Also, I usually get extremely helpful tracebacks explaining the root cause of the problem - I had one case of fourteen levels of traceback, where the true culprit was found. But that is from a complete analysis, not the desktop analysis that I believe gives a more lightweight check.
|
|
|
|
|
Thing is that the error I saw implied that Coverity wasn't correctly analysing the code in the C++ runtime - when a function is called with a parameter supplied with a statically constant argument value (defined using C++'s constexpr keyword, which is equivalent to a numeric literal), the flow analysis should be able to detect that the conditional code (which would have raised the exception) is not going to be executed, so the exception cannot be raised. That is not something that would be solved by suppressing some of the checks.
The tracebacks were very helpful - that part was absolutely what I'd want to see! In the end, though, the error came down to this function:
void __CLR_OR_THIS_CALL clear(iostate _State, bool _Reraise)
{ _State &= _Statmask;
_Mystate = _State;
const auto _Filtered = _State & _Except;
if (_Filtered)
{
if (_Reraise)
{
_RERAISE;
}
const char * _Msg;
if (_Filtered & ios_base::badbit)
{
_Msg = "ios_base::badbit set";
}
else if (_Filtered & ios_base::failbit)
{
_Msg = "ios_base::failbit set";
}
else
{
_Msg = "ios_base::eofbit set";
}
1. exception_thrown: An exception of type std::ios_base::failure is thrown.
_THROW(failure(_Msg));
}
}
Trouble is that _State was passed as std::ios_base::goodbit, which the C++ standard defines as being zero (and it's defined as such in therelevant header). This mans that the local variable _Filtered must be zero (as zero bitwise-and anything equals zero), so the if (_Filtered) if block will never be executed.
I do have a history of stumbling over bugs in static analysis tools, mind - I found one in PRQA-C when using it at work to analyse an embedded software project. That bug caused PRQA to think that arrays were one element smaller than they'd been declared (i.e. PRQA would think that bool array[10]; had 9 elements, not 10...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I would be suprised if Coverity was flawless 
From your description it seems like something I would raise as a support case (becauses we pay for support... ). But before that, I would check one thing: I have notices that the visibilty of a function can strongly affect which issues are raised. For a symbol (such as a function name) that is globally visible, the analysis must assume that any (syntactically legal) argument value may be supplied. For a private function, where all callers and calls are known, the analysis can ascertain that some code will never be called. (If that was the case here, Coverity would have flagged the entire if-statement as unreachable code - it is very good at that.)
In the general case, that exception may be thrown; the code is definitely reachable (from other calls, with other _State values) - you can't delete it. But for your specific call, with one specific _State value, the traceback should have been aborted and no issue raised.
The question is: Did the analyzer actually analyze the clear() source code? For the desktop analysis, it analyzes modified source lines only; for the rest, it uses the information from the previous complete analysis (somewhat similar to a referecded dotNet assembly: You have all the interface information, including an exception list, but none of the internal code flow). If it "knows" from earlier analysis results that clear() may raise an exception, it draw a fast conclusion from that.
I would be curious to know if you get the same result from a tabula rasa complete analysis, with all source code supplied, clear() inclusive. If your run was done as a desktop incremental analysis, I wouldn't be surprised if a full analysis did detect that the exception could not be reached in the specific call you make. The quick and dirty incremental analysis sure is quick compared to the full works, but it sometimes is a little dirty as well .
Or maybe we should say: Make it as fast as possible, but no faster. The problem is that if you demand all the qualities of a full analysis but performed on your desktop, it will be no faster that a full analysis.
|
|
|
|
|
Why not give PVS-Studio a try ? Built for Visual Studio and running as an extension, it gives very good insight into code. Also, open source projects can get a free licence.
modified 14-May-20 9:27am.
|
|
|
|
|
I did try PVS-Studio, and here[^] is a post about what I changed as a result of its findings. It provides a one-week free trial, after which you have to pay. I didn't see anything for open-source projects, and an email inquiring about pricing has gone unanswered.
Trying out Deep Code led to these[^] changes.
And there's one that I wrote: A Static Analysis Tool for C++[^].
I'm now going through Coverity's findings. The majority of them flag destructors for calling things that can throw. I don't know whether I'll fix these, because I catch the ensuing SIGABRT and prevent the program from exiting. However, this has occasionally led to a SIGABRT loop, which is worse than exiting. So I also have code that checks the stack for a destructor or delete operator before throwing. But a non-throwing version of a few things could be an improvement.
Coverity is good at analyzing execution paths, so besides these destructor things it tells you stuff like
- You already checked this for
nullptr, so why are you checking it again? - You're checking this for
nullptr now, so why didn't you bother when you first used it? - You're using an array index that could be out of bounds because it was returned by so-and-so function.
Naturally there are false positives, but I'd rather see them than not. A common one is that my parser will get the pointer from a unique_ptr, which then assigns ownership to another unique_ptr, after which I access the object through the original pointer. This gets flagged.
|
|
|
|
|
Message Closed
modified 14-May-20 9:26am.
|
|
|
|
|
|
and I was complaining about it to my wife.
Her reply.
"It's not that bad - keep your chin up!"
"No - the other chin..."
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I managed to lose weight despite my wife going all out on her kitchen abilities. Pies, cakes, pizza, lasagne... almost every day.
I just don't eat the junk food I eat when going to work and it works.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
My granddaughter asked me when I was going to get a training bra...I was not amused!
When you talk, you are only repeating what you already know.
But if you listen, you may learn something new.
--Dalai Lama
JaxCoder.com
|
|
|
|
|
because you're already an expert?
pestilence [ pes-tl-uh ns ] noun
1. a deadly or virulent epidemic disease. especially bubonic plague.
2. something that is considered harmful, destructive, or evil.
Synonyms: pest, plague, CCP
|
|
|
|
|
No I have not taken the test yet!
When you talk, you are only repeating what you already know.
But if you listen, you may learn something new.
--Dalai Lama
JaxCoder.com
|
|
|
|
|
you need a cert for that ! 
Wow!
(are there, like, authorities checking??)
pestilence [ pes-tl-uh ns ] noun
1. a deadly or virulent epidemic disease. especially bubonic plague.
2. something that is considered harmful, destructive, or evil.
Synonyms: pest, plague, CCP
|
|
|
|
|
lopatir wrote: (are there, like, authorities checking??)
Tag police...same ones that check for the tags on mattresses and such!
When you talk, you are only repeating what you already know.
But if you listen, you may learn something new.
--Dalai Lama
JaxCoder.com
|
|
|
|
|
Ever since lock-down, when I sit around the house, I sit arrrrrouuuuund the house.
|
|
|
|
|
DRHuff wrote: I am a little depressed
Pfft, you're not a little anything.
|
|
|
|
|
Regardless of your nationality, when you're in the bathroom, European…
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
modified 12-May-20 15:51pm.
|
|
|
|
|
|
or Europoopan?
When you talk, you are only repeating what you already know.
But if you listen, you may learn something new.
--Dalai Lama
JaxCoder.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
