Chris's Wiki :: blog/programming/ReleaseBuildsNoAbortOnWarnings Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/ReleaseBuildsNoAbortOnWarnings?atomcommentsDWiki2016-08-11T01:38:53ZRecent comments in Chris's Wiki :: blog/programming/ReleaseBuildsNoAbortOnWarnings.By Chris Siebenmann on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:f9499667eae99c4aacee306d0af228c7a8c947d5Chris Siebenmann<div class="wikitext"><p>I think that it's often a good idea to use <code>-Werror</code> in the development
version, in beta versions, and arguably even in release candidates,
because in each case it may smoke out problems and you have the chance
to fix any issues that come up before you freeze things. But an actual
release is frozen, at which point <code>-Werror</code> is a real problem.</p>
</div>2016-08-11T01:38:53ZBy Greg A. Woods on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:da7c3b189edeae2fc6d5726df73dacfff16c77dfGreg A. Woods<div class="wikitext"><p>I think in the old days when there were a lot more compilers and system types in use, and a lot more commonly used targets for popular compilers like GCC, that use of -Werror was potentially beneficial in avoiding real problems that might affect an program at run-time if a problem only showed up for some particular compiler or target system. Or at least that's the way I used to worry about it.</p>
<p>These days with fewer and fewer compilers, and an incredibly reduced range of target systems (at least for generally portable code to run on), I would agree this situation is now the other way around.</p>
<p>I do still run into problems with compiler and/or system- or architecture-specific warnings from older toolchains and less common target systems though. Most of the time I'm able to catch all of these myself, but sometimes I rely on strangers to find and report them. In these latter cases I do still waffle on whether -Werror would be the best way to get such reports or not.</p>
</div>2016-08-11T00:57:43ZBy Anon on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:cfb8914930180fd910d448f4de7276bb3e197076Anon<div class="wikitext"><p>cks, John: I stand corrected. I was wrong to say gcc 6 hadn't been officially released and it does look like it's justifiably hard to get new warnings into -Wall...</p>
</div>2016-07-21T20:12:23ZBy John Marshall on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:1b4e2ddbb1508e008dff11d7c39e3c831bb94786John Marshall<div class="wikitext"><p>Anon's complaints that <code>-Wmisleading-indentation</code> shouldn't be in <code>-Wall</code> are nothing new to the GCC developers. Some reasoning why it is included in <code>-Wall</code> is in <a href="https://gcc.gnu.org/ml/gcc/2016-05/msg00046.html">https://gcc.gnu.org/ml/gcc/2016-05/msg00046.html</a> and the surrounding thread.</p>
<p>People who like to write one-liners can suppress the warning with</p>
<pre>
if (...) { thing; } more-thing;
</pre>
<p>to emphasise exactly what's controlled by the <code>if</code>, or in other ways. Personally I find this no more objectionable than the <code>if ((a = b</code><code>))</code> excess parentheses used to suppress <em>did you mean <code>==</code></em> warnings that we're all used to.</p>
</div>2016-07-21T09:55:03ZBy Chris Siebenmann on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:0dd72024d42a70fee8459f0c117cba6919bcb1ecChris Siebenmann<div class="wikitext"><p><a href="https://gcc.gnu.org/">The official gcc site</a> says that gcc 6.1 is
an official release (and the latest version); gcc 7.0 is what's in
development. I'd also argue that this code does have misleading
indentation as written. The common idiom for an inline <code>for</code> loop
in C is:</p>
<blockquote><pre>
for (...) thing;
for (...) { thing; more-thing; }
</pre>
</blockquote>
<p>When you write:</p>
<blockquote><pre>
for (...) thing; more-thing;
</pre>
</blockquote>
<p>This certainly can be said to look like '<code>more-thing;</code>' is intended
to be part of the for loop based on indentation, but it actually isn't
because the <code>for</code> loop body is only a single statement. This is the
same sort of issue as:</p>
<blockquote><pre>
if (...) thing; more-thing;
</pre>
</blockquote>
<p>Again, this sort of looks like <code>more-thing;</code> is part of the <code>if</code> body,
but it isn't. I think both are worth complaining about under 'misleading
indentation'.</p>
<p>As far as filing a release critical blocker bug, the problem is that
1.10.0 has already been released. Rust can release 1.10.1 if they want
to, but they absolutely shouldn't go back and change the 1.10.0 release
so that it can compile with gcc 6. This especially becomes a problem
if you need to build older releases of software for some reason; these
older releases are permanently unbuildable and are very unlikely to get
new little point releases to fix their build issue.</p>
<p>(This particular problem has already been fixed in the Rust mainline,
of course. I don't know if the Rust people are considering a 1.10.1
release or if they ever do such minor releases except for critical
issues.)</p>
</div>2016-07-20T20:16:07ZFrom 31.17.248.110 on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:2bbc47584252e193a446d433b9259d1812de7d70From 31.17.248.110<div class="wikitext"><p>You're missing the obvious.</p>
<p>The Rust developers have decided that -Wall -Werror is a part of their official release cycle. So obviously you should immediately file a a release-critical (type blocker) bug against the software.</p>
</div>2016-07-20T19:47:48ZBy Anon on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:0d2c2db4698c4218de91594da19e79ea18066739Anon<div class="wikitext"><p>One more thought - if the default standard the compiler uses changes and you don't specify which standard you're trying to adhere to then you CAN get the case where your code is "more broken" than it was before but a warning might have saved you...</p>
</div>2016-07-20T17:55:04ZBy Anon on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:23a821fcbd7f2ec7f01834dc48f7817532bf229cAnon<div class="wikitext"><p>I'd argue this is a bug in GCC6 (which itself is still unreleased and experimental) has a bug - it's flagging code that doesn't actually have misleading indentation - rather the author felt like creating a one liner.</p>
<p>It's a shame that Wmisleading-indentation falls under Wall than Wextra (as shown by <a href="https://github.com/Barro/compiler-warnings/blob/master/gcc/warnings-gcc-6.txt">https://github.com/Barro/compiler-warnings/blob/master/gcc/warnings-gcc-6.txt</a> ). However I think Werror can be used if you explicitly mark which warnings you want to be errors rather than letting the compiler make all warnings errors (but perhaps that makes your compile non-portable)...</p>
</div>2016-07-20T17:41:34ZBy Alex Xu (Hello71) on /blog/programming/ReleaseBuildsNoAbortOnWarningstag:CSpace:blog/programming/ReleaseBuildsNoAbortOnWarnings:652ec51a0c3c6c527f96b106082ab0f0ba9b26b0Alex Xu (Hello71)<div class="wikitext"><p>It has been Gentoo policy for many years to always remove -Werror in ebuilds: <a href="https://devmanual.gentoo.org/ebuild-writing/common-mistakes/#-werror-compiler-flag-not-removed">https://devmanual.gentoo.org/ebuild-writing/common-mistakes/#-werror-compiler-flag-not-removed</a>.</p>
</div>2016-07-20T12:37:18Z