<div dir="ltr"><font face="georgia,serif"><br></font><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 10:57 AM, Nadav Har'El <span dir="ltr"><<a href="mailto:nyh@math.technion.ac.il" target="_blank">nyh@math.technion.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Apr 04, 2012, Oleg Goldshmidt wrote about "Re: [YBA] kernel compile errors with GCC >= 4.6":<br>
<div>> On Wed, Apr 4, 2012 at 10:03 AM, Jonathan Ben Avraham <<a href="mailto:yba@tkos.co.il" target="_blank">yba@tkos.co.il</a>>wrote:<br>
><br>
> > Dear linux-il colleagues,<br>
> > GCC 4.6 introduced many new warnings that cause -Werror to stop the<br>
> > compilation for some platforms, such as powerpc, in various files.<br>
><br>
> Oh, I didn't even know they finally introduced -Werror... Good.<br>
<br>
</div>Why is this good?<br></blockquote><div><br>Well, one reason is that there have been calls from many directions to make this happen. ;-) Now to why there were such calls?... <br><br>I don't really think I need to explain - least of all to you - why -Werror is good. We all know that it does not let the developer to ignore warnings. All warnings indicate problems that are waiting to happen once explicit or implicit assumptions that the problem will not occur are broken. It is very difficult for me to come up with an example where there is NO chance that there may be a problem (even a seemingly innocuous "initialized but not used" may appear because someone inadvertently removed one line more than needed, started a compilation of a large and complicated product, and went to grab a coffee - -Werror would force another look). On the other hand, real life examples where paying attention to warnings saves the day abound.[1] <br>
<br>Now let's discuss relevant use-cases. Say you lead an open source project - not necessarily a Linux kernel, but something that has lots of contributors whom you wish to trust to some extent, but you won't have the bandwidth to check everything. Forcing everybody to use -Werror seems a very good idea in this case.<br>
<br>Oh, you say, but what if a new version of the compiler reacts to more stuff than the latest on your computer? So, someone will notice that first. Typically on FOSS (e.g., kernel), it will be a developer who will either patch or inform the maintainer.<br>
<br>Oh, but what if you deliver your code in source form to end users and they - not developers or maintainers - need to compile it? And one of them happens to use Fedora 23 rc4 beta with gcc-5.6.7? Well, you did provide a Makefile that allows the use to do "make all WERROR=no"[2], right? And you wrote it in the README, I am sure. Or, better yet, the procedure is "./configure && make && sudo make install" and your ./configure script has a --without-werror option, right?<br>
</div><div><br>Obviously, the kernel has such a facility that will help anyone who tries to compile the kernel. Most likely an experienced person will encounter it first, and if he is baffled at first then Linux-IL or equivalent will render assistance. ;-) And we all hope YBA will send a patch...<br>
<br>[1] I am helping to evaluate a sizeable body of C++ code - a product - these
days. Don't let me start... The developers didn't use any warnings, or
maybe they originally did, saw lots of them, decided to ignore them,
switched everything off... My favourite of the last 2-3 days favourite
was a warning, in a few places, of non-void functions not returning
anything. Often this means that the return value is not checked for validity, etc., but this case was more interesting. Turned out the warnings were for output operators for some user-defined
classes that did not return a reference to the stream. It so happened
that everything was fine because these operators were never used in an
output chain (of the "cout << x << y;" type) - in the
current code. We would buy the code and modify it or just write client
applications or whatever. Just a bunch of -W options (I use a fair amount) would just flush a
huge number of warnings, some of which would be harmless (under
reasonable, but not all, conditions - there is always an assumption
involved, remember). If this were encountered at runtime it might take some time to find. <br><br>[2] One kinda cute (though not necessarily the best) way to do it - only with GNU make - is something like<br><br>override CFLAGS := -Wall -Wextra <and many more -W flags> -Werror $(CFLAGS)<br>
<br>which allows one to say "make CGLAGS+=-Wno-error" (or "make CFLAGS+=-Wno-error=<x>") on the command line. This is the only way I know of to *append* to a make variable via the command line ;-)<br>
<br></div></div>-- <br>Oleg Goldshmidt | <a href="mailto:oleg@goldshmidt.org" target="_blank">pub@goldshmidt.org</a><br>
</div>