Please turn it on in your browser preferences.
for specific sites, we recommend the
Review Request #428
Created April 4, 2017 and submitted Aug. 4, 2017, 6:09 p.m.
I suspect this is actually mis-detected.
I suspect you're right and it is a false positive. I would be more inclined to suppress the warning.
I do understand the temptation, but our goal should be suppressions removed, not added.
We shouldn't be blindly initializing everything gcc thinks is uninitialized as well. I'd really love to understand why it does think so.
it is not done just "blindly" - if you look on it, why x2 and not y2? also same will go for x1 and y1. I actually do suspect the gcc 6.3 bug there, and thats really about making "mental note" - unfortunately I have no information if anyone is actually working on gcc to get the root cause identified and fixed. I have no time to do that myself and this is exactly the reason why I'm posting those reviews - maybe someone will finally step up. At least, at this time we actually do have the compiler packaged, so we can do something.
I would still go for supressing the warning along with a comment in the appropriate makefile pointing the finger at GCC.
Maybe it would be better to move this initialization right before the actual initialization at line 140, so the fun is even more obvious.
If we're fixing braces, should this be pulled up a line?
Is there a chance that this assignment is what's screwing up gcc's analysis?
I definitely also suspect it, but there is still the question why it only does happen with x2, and not for y2, or x1/y1 pair. Probably the mechanics is more complicated of course; in some other cases it also seems the if statement can have some influence; and/or perhaps something about how they are trying to predict the execution paths. I think this issue is something not to hurry about anyhow - there are more obvious ones and hopefully at some point we can have enough analysis about gcc 6 there to understand the root cause better.
Quite surely. And I took different kind of approach for workaround - instead of pointer games, using union.
Revision 2 (+29 -43)
use unsigned/float union.
Revision 3 (+74 -75)