|
|
|
|
|
by tenfingers
4573 days ago
|
|
It always surprised me that GCC has no source-level way of controlling compiler warnings. Many programmers (and gcc apparently) live with the assumption that compiler warnings must always be fixed. This is largely false. Compiler warnings are there to help with additional information, not to be something to fix. There are many cases where the compiler issues a warning which must be ignored. Many compilers support pragmas to silence a specific warning class in a specific point in the code. IMHO it's a much better approach to silence just a single warning instance where you know the compiler is getting the wrong assumption than silencing a whole warning class like the article suggests. But it seems that in GCC you have no choice. Instead, code written with/for gcc often silences the warning by inserting some dummy code. For instance, the "unitialized warning" is usually fixed by assigning the variable to itself. It's shitty to look at, and someone that doesn't know this trick might wonder why this is being done. I've reported a feature request many years ago, and it was quickly closed... |
|
Also work for clang like so (replace clang with GCC for its version):