[YBA] kernel compile errors with GCC >= 4.6
Orna Agmon Ben-Yehuda
ladypine at gmail.com
Thu Apr 5 11:09:55 IDT 2012
On Thu, Apr 5, 2012 at 10:57 AM, Nadav Har'El <nyh at math.technion.ac.il>wrote:
> On Wed, Apr 04, 2012, Oleg Goldshmidt wrote about "Re: [YBA] kernel
> compile errors with GCC >= 4.6":
> > On Wed, Apr 4, 2012 at 10:03 AM, Jonathan Ben Avraham <yba at tkos.co.il
> >wrote:
> >
> > > Dear linux-il colleagues,
> > > GCC 4.6 introduced many new warnings that cause -Werror to stop the
> > > compilation for some platforms, such as powerpc, in various files.
> >
> > Oh, I didn't even know they finally introduced -Werror... Good.
>
> Why is this good?
>
> In the (very) old days, there was a clear separation: The compiler
> gave you *errors*, and a separate program, call "lint",
> (http://en.wikipedia.org/wiki/Lint_%28software%29) was used to find
> various risky code, possible bugs, unused variables, and so on, and
> warn on them.
>
> I *don't* like the fact that modern compilers decide to complain on
> issues of questionable style, such having a variable which is never
> used, using "=" (deliberately, not ==) in an "if"'s expression, and so
> on. I like even less the trend to use something like "-Werror" to *abort*,
> not just warn, on these cases.
>
> After our last Hspell release, I started receiving complaints from
> various people who used slightly different compilers than I did, so got
> different *warnings* that I didn't get. This was very annoying, because
> although I could (and did) fix those warnings, most of them did not have
> any merit, and the only reason why I made many of these changes was to
> "appease" the compilers. In one example, the compiler wrongly deduced that
> a
> variable could be used before being set, which was false (I can explain
> why,
> but the details aren't important here). In another example, a header file
> defined a few static arrays, and not all of them were needed in each
> including file - and the compiler complained about the defined-but-not-used
> static arrays.
>
> I think all of this is bad. I agree that it's useful to have a tool
> (lint, gcc -Wall, or whatever), for the *developer* to find possible
> problems. But the developer shouldn't *have* to change the code to
> appease this tool, if he doesn't want to. The compiler that a *user*
> of this code uses should definitely not attempt to look for such
> "possible" problems, and most definitely should not abort the
> compilation if it finds some. The contract between the programmer and
> the user is that the programmer writes the code as carefully as he can -
> and the user tries the best he can to compile it, NOT find reasons for
> the compilation to fail. See also
> http://en.wikipedia.org/wiki/Postel%27s_law
Postel's law leaves room future standard modifications, but it seems to me
it is also
the source of many vulnerabilities. For example, one of the zero day
vulnerabilities
used by Stuxnet is that free text could be inserted before real code, and
was ignored.
This allowed a place for the Stuxnet code.
So, if you wish to write a defensive system, you should stick with what you
know is true -
be conservative both in what you send and what you receive.
>
>
> If -Werror is used in a big-enough project, there is a very high
> probability that compilation will always fail when a new version of the
> compiler is first tried. I fail to see why this is a good thing.
>
> --
> Nadav Har'El | Thursday, Apr 5
> 2012,
> nyh at math.technion.ac.il
> |-----------------------------------------
> Phone +972-523-790466, ICQ 13349191 |Someone offered you a cute little
> quote
> http://nadav.harel.org.il |for your signature? JUST SAY NO!
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
--
Orna Agmon Ben-Yehuda.
http://ladypine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120405/8008ca63/attachment.html>
More information about the Linux-il
mailing list