Go has the equivalent of -Werror on all the time. How does it address the issue of "your compiler might emit a warning that my compiler didn't?"
Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go). Aside - I seem to remember a Blog post you wrote on your experience with the Go lang…
Don't use -Werror
21–30 of 74 posts
Re: Don't use -Werror
#22Summary: Enable -Werror in debug builds, disable it in production builds (in publicly released builds). Reason: -Werror is helpful for you, useless for a 3rd party.
In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take months to fix something that's literally not a problem yet.
By the way, I couldn't build MariaDB on this one machine because some plugin we don't use has -Werror set and fails with obscure C++ nonsense.
Re: Don't use -Werror
#23Re: Don't use -Werror
#24Re: Don't use -Werror
#25I use -W4 and -WX with MSVC to enable the highest warning level and flag all warnings as errors. Then I disable a couple of the more pointless warnings (unreferenced formal parameter, unreferenced local function, unreachable code...) that would otherwise keep me from being able to use -W4 without jumping through arbitrary hoops. The problem with GCC, at least at the time I was using it several years ago, is that ther…
-Wno-specific-warning (I think it's always had this, or at least for a very long time).
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wspecific-warning"
#pragma GCC diagnostic ignored "-Wspecific-warning"
...
#pragma GCC diagnostic pop
For warnings you want to disable in a smaller scope. s/GCC/clang/ for clang. Bonus points: #define MM_WARNING_IGNORE_GCC(x) MM_IF_GCC( _Pragma(GCC diagnostic ignored x) )
#define MM_WARNING_IGNORE_CLANG(x) MM_IF_CLANG( _Pragma(clang diagnostic ignored x) )
#define MM_WARNING_IGNORE_MSVC(x) MM_IF_MSVC( __pragma(warning(disable: x)) )
#define MM_WARNING_PUSH() \
IF_GCC( _Pragma(GCC diagnostic push) ) \
IF_CLANG( _Pragma(clang diagnostic push) ) \
IF_MSVC( __pragma(warning(push)) )
#define MM_WARNING_POP() \
IF_GCC( _Pragma(GCC diagnostic pop) ) \
IF_CLANG( _Pragma(clang diagnostic pop) ) \
IF_MSVC( __pragma(warning(pop)) )
MM_WARNING_PUSH()
MM_WARNING_IGNORE_GCC("-Wspecific-warning")
MM_WARNING_IGNORE_CLANG("-Wspecific-warning")
MM_WARNING_IGNORE_MSVC(1234)
...
MM_WARNING_POP()
Defining MM_IF_*() is left as an exercise to the reader.Re: Don't use -Werror
#26Why can't developers, y'know, ACTUALLY READ THE BLOODY WARNINGS? And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
Re: Don't use -Werror
#27Earlier quoted context omitted.
-Wno-specific-warning (I think it's always had this, or at least for a very long time).
And: #pragma GCC diagnostic push #pragma GCC diagnostic warning "-Wspecific-warning" #pragma GCC diagnostic ignored "-Wspecific-warning" ... #pragma GCC diagnostic pop For warnings you want to disable in a smaller scope. s/GCC/clang/ for clang. Bonus points: #define MM_WARNING_IGNORE_GCC(x) MM_IF_GCC( _Pragma(GCC diagnostic ignored x) ) #define MM_WARNING_IGNORE_CLANG(x) MM_IF_CLANG( _Pragma(clang diagnostic ignored…
Re: Don't use -Werror
#28Earlier quoted context omitted.
Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go). Aside - I seem to remember a Blog post you wrote on your experience with the Go lang…
Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.
Re: Don't use -Werror
#29Why can't developers, y'know, ACTUALLY READ THE BLOODY WARNINGS? And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
Same reason checklists are handy: People automatically optimize away "dead code" (nevermind the fact that reading the warnings is sometimes useful.)
> And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
I do get multiple errors with -Werror and kin, FWIW. But again we run into human nature - C++ errors get unreliable after the first one, so people tend to optimize away the "useless" step of reading the second error...
Re: Don't use -Werror
#30Summary: Enable -Werror in debug builds, disable it in production builds (in publicly released builds). Reason: -Werror is helpful for you, useless for a 3rd party.