Bugs found in GCC with the help of PVS-Studio(viva64.com)
viva64.com
Bugs found in GCC with the help of PVS-Studio
http://www.viva64.com/en/b/0425/
7 comments
Thanks. That provides pointers to the specific issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77444
--
And fixes have also started coming in:
https://gcc.gnu.org/viewcvs?rev=239959&root=gcc&view=rev
Kudos for investigating and reporting the issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77444
--
And fixes have also started coming in:
https://gcc.gnu.org/viewcvs?rev=239959&root=gcc&view=rev
Kudos for investigating and reporting the issues.
a == 1 || a != 2 needs a warning but it's not necessarily a bug
sometimes I may keep overlapping expressions in a statement to remind me of the triggers I'm looking for at this point - and would likely use some meaningful constant names for the 1 and 2
statements aren't just logic - they're often documentation too - especially on code you might not look at again for months
I used to have many arguments with a professor whose code I was working on - he would factor out everything in an expression - removing all the parentheses and rely on operator precedence - it was often impenetrable (for me) - so I'd unpack it, wrap parentheses everywhere, change single letter vars to meaningful ones etc. - he'd be in my office an hour later ranting
sometimes I may keep overlapping expressions in a statement to remind me of the triggers I'm looking for at this point - and would likely use some meaningful constant names for the 1 and 2
statements aren't just logic - they're often documentation too - especially on code you might not look at again for months
I used to have many arguments with a professor whose code I was working on - he would factor out everything in an expression - removing all the parentheses and rely on operator precedence - it was often impenetrable (for me) - so I'd unpack it, wrap parentheses everywhere, change single letter vars to meaningful ones etc. - he'd be in my office an hour later ranting
> a == 1 || a != 2 needs a warning
Yes, it needs a warning because it's kind of obvious that there is something amiss about this expression. Only the author could tell what was specifically wrong.
Yes, it needs a warning because it's kind of obvious that there is something amiss about this expression. Only the author could tell what was specifically wrong.
Yes
I would advocate for the maintenance of both expressions if the comparison is tricky
If this is a hot path that must absolutely be optimized then a comment explaining the conditions is needed
And of course, the != 2 question might change (either because of a bug or logic change) but the == 1 might still be valid, however, if you took the first one your change will break the code
I would advocate for the maintenance of both expressions if the comparison is tricky
If this is a hot path that must absolutely be optimized then a comment explaining the conditions is needed
And of course, the != 2 question might change (either because of a bug or logic change) but the == 1 might still be valid, however, if you took the first one your change will break the code
If you're suggesting that discovery of a bug in a popular open source project holds the discoverer up to a moral responsibility of reporting it -- well then, maybe you are guilty too!
There's no obligation to report a bug you've found, of course. But if you've taken the time to write a blog post about it, one would hope you've also taken the time to directly notify the software authors as well.
But if you hadn't taken as much time -- say you've only come across a well written blog post clearly describing the bug -- would you report it?
Given (1) the blog post, (2) the author posted the blog link on HN, I assumed that the bugs would have reported upstream.
If it were a blog describing a 0-day vulnerability in a given software, I wouldn't have assumed that it would have been reported.
If it were a blog describing a 0-day vulnerability in a given software, I wouldn't have assumed that it would have been reported.
There's a mistake in the analysis of the ternary operator in the assert that doesn't check anything. Not only does the ternary ?: operator have lower precedence than the comparison <= operator, but it also has lower precedence than the logical && operator. So the expression inside the assert doesn't resolve to (die_offset > 0), it resolves to either 0xffff or 0xffffffff, both of which are true. The assertion really doesn't check anything at all.
PVS-Studio (or more specifically Andrey) used to do a really nice program called "CppHints", where they would email a little tip each day (and later each week I think).
Anyway, I guess I just wanted to say, Andrey, I appreciated your work and enjoyed reading those tips! Thanks!
Anyway, I guess I just wanted to say, Andrey, I appreciated your work and enjoyed reading those tips! Thanks!
This is now my favorite blog.
Andrey, any plans to support Objective-C? (You are flagging things I can't get clang to warn about.)
Andrey, any plans to support Objective-C? (You are flagging things I can't get clang to warn about.)
Not yet. We are now experimenting with C# support and with Linux support. What's next, we do not know yet. There are two perspective areas: Objective-C and Java.
Objective-C would be a bad idea now, it seems to be replaced by Swift at an impressive rate.
Java or JVM?
Since PVS is a static source-level checker, I don't see how it would make sense to check JVM bytecode.
Java
I gather there's no relationship to the Prototype Verification System from SRI [0].
[0] http://pvs.csl.sri.com/index.shtml
[0] http://pvs.csl.sri.com/index.shtml
Yes. No relationship. PVS: OOO "Program Verification Systems" (Co. Ltd.)
Andrey, why did you title this different than your blog post?
I like that one.
"Bugs found in GCC with the help of PVS-Studio"
I like that one.
"Bugs found in GCC with the help of PVS-Studio"
We've updated the submission title from “GCC bugs”.
Thankfully, the world is changing. You have languages where variables are immutable by default or can be declared so that would prevent issues as http://www.viva64.com/en/d/0108/
Maybe gcc should do better for static analysis of a program. Expressions like `a && a` or `a == 1 || a != 2` should be caught easily.