Page 2 of 3
Re: Static code analysis
Posted: Mon Jan 02, 2012 5:29 pm
by Love4Boobies
Synon wrote:Love4Boobies wrote:Synon wrote:I compile with -Wall -Wextra -pedantic -ansi -std=C99 when I'm adding a feature, but I add -Werror and change -pedantic to -pedantic-errors when I get it working.
-ansi is C89, -std=C99 is C99. It's either one or the other.
I put both, I thought -ansi meant it would only use standard features. I'll take the -ansi out.
No, that's already covered by -std=c99. If you want to use the GNU dialect, you have to use -std=gnu99 instead.
Synon wrote:@Combuster,
Lol, surely -Wall and -Wextra account for all of those? I mean, -Wall is "enable all warnings" so I would've thought it would, you know, enable all warnings...
They account for some of them. See the simplified list I provided in my last reply.
Re: Static code analysis
Posted: Mon Jan 02, 2012 5:52 pm
by Owen
Love4Boobies wrote:Synon wrote:Love4Boobies wrote:-ansi is C89, -std=C99 is C99. It's either one or the other.
I put both, I thought -ansi meant it would only use standard features. I'll take the -ansi out.
No, that's already covered by -std=c99. If you want to use the GNU dialect, you have to use -std=gnu99 instead.
Note that GCC-specific features remain available - they just only get made available in reserved namespaces. IMO, defaulting to a non-strict mode is GCC's biggest bug.
Re: Static code analysis
Posted: Thu Jan 05, 2012 2:00 am
by Solar
Synon wrote:Lol, surely -Wall and -Wextra account for all of those? I mean, -Wall is "enable all warnings" so I would've thought it would, you know, enable all warnings...
Do. Not. Assume.
The GCC docs say about -Wall, emphasis mine:
Note that some warning flags are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Some of them are enabled by -Wextra but many of them must be enabled individually.
Re: Static code analysis
Posted: Thu Mar 22, 2012 6:56 am
by Andrey2012
Hello. I would invite all who are interested in static code analysis, try our tool PVS-Studio.
PVS-Studio is a static analyzer that detects errors in source code of C/C++/C++11 applications (Visual Studio 2005/2008/2010).
Examples of use PVS-Studio:
100 bugs in Open Source C/C++ projects.
Fully functional trial:
download.
Re: Static code analysis
Posted: Thu Mar 22, 2012 7:13 am
by Yoda
Re: Static code analysis
Posted: Thu Mar 22, 2012 11:55 pm
by Combuster
It stinks. It requires a paid version of M$VS.
(Would've expected something like that from a bot)
Re: Static code analysis
Posted: Thu Mar 22, 2012 11:59 pm
by Andrey2012
Combuster wrote:It stinks. It requires a paid version of M$VS.
Why doesn't PVS-Studio support Visual Studio Express Edition?
This is not the restriction of PVS-Studio. None of the Visual Studio Express Edition versions supports plugins - this is the restriction of this very Visual Studio edition; we cannot integrate our tool into Visual Studio Express Edition.
Re: Static code analysis
Posted: Fri Mar 23, 2012 12:06 am
by Combuster
That's your design choice to write an implementation with that requirement, not Microsoft's.
Re: Static code analysis
Posted: Fri Mar 23, 2012 9:27 am
by Brynet-Inc
The amount of people on this forum using Visual Studio for OSDev is negligible, the are other free static analysis tools. Please peddle your product elsewhere.
Re: Static code analysis
Posted: Fri Mar 23, 2012 12:22 pm
by brain
Hmm, the last tool I used similar to this was RATS... showing how long ago that was eh...
Re: Static code analysis
Posted: Sat Mar 24, 2012 4:46 am
by Rudster816
Combuster wrote:That's your design choice to write an implementation with that requirement, not Microsoft's.
According to the product page, you can launch it via the command line as well. Either way, its a commercial product, I don't think a software company\team is going to be using an express edition of Visual Studio. I will say that posting the trail here is pretty useless because anyone looking into OSDev is almost certainly doing it on his own time, and isn't going to be able to afford or want a commercial product like that.
On a related note, I suddenly find that my code could have benefited from a product like that.
I was using this bit of code...
Code: Select all
...
#define CHUNK_POOL_INDEX_PUSH(x) chunk_pool_stack--; *chunk_pool_stack = x
unsigned short* chunk_pool_stack;
...
int i;
...
for (i = 65535; i >= 0; i--)
CHUNK_POOL_INDEX_PUSH(i);
Which to my surprise, would decrement the stack pointer all the way down, but only set the last element, not to 0 though, but to 65535. I'll let you try and figure it out without spoiling the fun.
Answer:
Only the first statement in the macro was run through the loop, since without braces only the statement immediately following the for loop will be executed. So it expanded to this
for (i = 65535; i >= 0; i--)
chunk_pool_stack--;
*chunk_pool_stack = i;
since i is now -1, the last element is set to 65535, not 0 as you would expect.
Correct code:
for (i = 65535; i >= 0; i--)
{
CHUNK_POOL_INDEX_PUSH(i);
}
Even better would be not to use multiline macros that look like single statements. Luckily it only took me a minute or two to catch this after testing it.
Re: Static code analysis
Posted: Sat Mar 24, 2012 5:05 am
by bluemoon
You may also enclose it within the macro:
Code: Select all
#define CHUNK_POOL_INDEX_PUSH(x) { chunk_pool_stack--; *chunk_pool_stack = x }
Re: Static code analysis
Posted: Sun Mar 25, 2012 7:41 am
by Synon
@Rudster816
I would wrap the macro in
so you can't make that mistake again. I do that with all macros that are more than one statement (I got the idea from Linux).
Re: Static code analysis
Posted: Sun Mar 25, 2012 8:11 am
by qw
Another but non-standard (GCC specific) solution is to wrap the curly brackets between parentheses:
Re: Static code analysis
Posted: Sun Mar 25, 2012 11:07 pm
by Solar
Hobbes wrote:Another but non-standard (GCC specific) solution...
I wonder, why bring up a "non-standard, compiler-specific" solution at all when the canon, general solution has already been presented?