<story><title>-Werror Is not your friend (2017)</title><url>https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/</url></story><parent_chain><item><author>sgerenser</author><text>Within a company (at least in my experience) compilers&amp;#x2F;toolchains are changed infrequently, usually less than once a year. In this case, keeping the software building with -Werror is a heck of a lot easier than allowing warnings to creep in, then trying to fix it later. It ends up that “later” never happens. Using -Werror from the very beginning forces you to address warnings: either by silencing obviously false positives, or fixing legitimate problems.&lt;p&gt;A previous company I worked at had large C++ projects that built with 5000+ warnings. Nobody looked at them, obviously. Buried within them I recall one about printf-style formatting string mismatching arguments, that said something like “mismatching arguments will cause a crash if this code is executed.” I only noticed it buried in the list of warnings after debugging a segfault caused by that line of code.</text></item></parent_chain><comment><author>lolinder</author><text>I feel like you&amp;#x27;re replying to the title and not the article. The article starts with a huge disclaimer saying that the author has no tolerance for warnings getting merged in to their projects, but they have the warnings check in the CI pipeline. Doing that would totally prevent the kind of lax never-fixed errors you&amp;#x27;re talking about, while allowing more flexibility while the PR is still in progress.</text></comment>
<story><title>-Werror Is not your friend (2017)</title><url>https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/</url></story><parent_chain><item><author>sgerenser</author><text>Within a company (at least in my experience) compilers&amp;#x2F;toolchains are changed infrequently, usually less than once a year. In this case, keeping the software building with -Werror is a heck of a lot easier than allowing warnings to creep in, then trying to fix it later. It ends up that “later” never happens. Using -Werror from the very beginning forces you to address warnings: either by silencing obviously false positives, or fixing legitimate problems.&lt;p&gt;A previous company I worked at had large C++ projects that built with 5000+ warnings. Nobody looked at them, obviously. Buried within them I recall one about printf-style formatting string mismatching arguments, that said something like “mismatching arguments will cause a crash if this code is executed.” I only noticed it buried in the list of warnings after debugging a segfault caused by that line of code.</text></item></parent_chain><comment><author>ninkendo</author><text>&amp;gt; either by silencing obviously false positives&lt;p&gt;(Off-topic) Oh how I wish this were possible in the language I use at $dayjob. Swift does not let you silence warnings on a line by line basis. It’s easily one of the top 5 worst things about the language.</text></comment>