The opinions of (future) compiler authors decides already wether your programm will work in all cases. With those warnings they indicate some of their decisions.
Future compiler authors are at least in theory beholden to current language specifications. If a program does something legal that a compiler author feels is a bad idea, the compiler can whine all it wants, but it still has to compile the program. Compilers drop support for older specifications far less often than they add new warnings.
This is especially true for warnings about && and || precedence. When you use those two operators in one expression without parentheses, IIRC both gcc and clang complain, but I once wanted to compile some software that thought it was a good idea to -Werror all the code and don't use parens around &&. Fun times fixing all the zillion makefiles that mentioned Werror. (Yay autoconf?)
That's the one warning that I like to disable. I hate having to write superfluous parentheses around conjunctions. I mean, come on. It's just as lame as requiring them around multiplications would be.
Even if /you/ know the order of operations, making them explicit with the parentheses provides clarity and allows future maintainers to quickly (and correctly) deduce the structure of the logical construct.
I generally only leave them out in short simple to follow 'normal math' order of operations.
Sure. The rule you suggest might be good coding practice --- but people can disagree, and their omitting the extra braces doesn't make the code wrong. An existing correct program shouldn't one day stop building because someone added a warning that enforces your preferred operating precedence marking style.
To be fair, a compiler contains all the infrastructure you'd want in a linter. I don't mind compilers having lint-like warnings: I just want them to very clear about the differences between these warnings and warnings that reflect functional problems with high probability.
What I’d like is for compiler authors to just admit this and include a lint mode.
There’s some practical and political difficulty with adding new warnings to a widely used compiler, partly because you don’t want to generate too many new warnings for existing code, partly because people compile with -Werror and upgrading the compiler will break (well, sprain) their build. Those difficulties would be easy to skirt by just tossing new warnings into lint mode and promoting them to compiler warnings if they turn out to be very useful in practice.
The C standard is dropping support for things like gets, a compliant modern compiler should fail to build any code that uses that. This is very controversial with compilers - and gets is among the most horrid thing that ever made it into a compiler.
In general yes, but the posts above were talking about a warning about undefined behavior, so the standard says that anything could happen in that case.
