[YBA] kernel compile errors with GCC >= 4.6

[Oron Peled]

On Thursday, 5 בApril 2012 14:28:42 Nadav Har'El wrote:
> On Thu, Apr 05, 2012, Oron Peled wrote:
> > Many FOSS projects (and the kernel in particular) are very distributed,
> > so there are potentially hundreds of "Linus Torvalds's" out there.
> 
> Let's say that I'm developing a particular driver.
> Do I need to see warnings when some other driver, not directly related
> to my project, didn't use a variable?

Let's see how these dreaded warnings get there in the first place:
 - There was no '-Werror'
 - The "other" developer didn't notice/care about the warnings
 - You would care even less about someone else warnings
 - No problem... "someone else" would clean the mess

Can you see the vicious circle that leads to ?

Preventing code deterioration is winning strategy over trying to fix
it later -- yes it has its (small IMO) price.

> The few people who work on the whole kernel, including the so-called
> "Kernel Janitors", Redhat's QA people, and similar people, should
> probably compile with -Wall -Werror and use any other
> possible-bug-catching tools they can get their hands on.

And when they see tens of "uninitialized variable" warnings,
they'll know best how to initialized them and to what values...
Yes, they must know better than the original code writer...

Nadav, you are experienced enough to know first-hand that fixing bugs
closer to the point of their creation is easier by orders of magnitude
than trying to clean them up afterwards (say, in QA, or worse on Beta-site)

> But the ordinary users,
Are not compiling kernels...

> and even ordinary developers
Now we are talking...

> - they should not have to constantly spend their time figuring out
> problems in other parts of the code they know nothing about.

Let's separate reality from wishfull thinking. How many times you
had to debug into a library you didn't write? (that's not related
to our compilation talk, just a different example).

Something does not compile cleanly? Good! Make noise about it,
rant about it, in bugzilla, your blog, mailing-list, whatever.

This will help solve the bug quicker than to ignore it (no -Werror)
and find out later that you have to (run-time) debug into that
nasty code (which you didn't write).

> > Practically any developer working on some obscure Linux driver within
> > some company is producing code which *may* eventually reach the kernel
> > proper. Using global -Wall -Werror put most of the burden where it
> > should be -- on the shoulder of the one writing the code, instead
> > of starting to resolve these issues upon merging it upstream.
> 
> Indeed - let the writer of the code use -Wall -Werror. He'll also need
> to use checkpatch.pl (to check the coding style), and maybe he'll use
> various other tools to help him write quality code. But none of these
> "scaffolding" needs to reach the end-user build process.

He will not. Because if that's not the default, turning it on is bound
to expose tons of (now fatal) warnings.

Believe me, I've seen it happen in proprietary software -- low
coding standards (no-time), no time to fix warnings (just to
appease the compiler), its a never-ending task (because new
warnings are generated all the time).

It only stopped after a critical memory corruption forced the
company to invest the time -- they now use '-Werror'
(otherwise, in a few months it'll be back as it was)

> I tried to avoid the details, but since you asked, here they are.
> Imagine code like this:
> 
> 	extern int flag;
> 
> 	...
> 
> 	void f(){
> 		int i;
> 		if (flag)
> 			i=0;	
> 		g();
> 		if (flag)
> 			dosomething(i);
> 	}
> 
> Now, the compiler (starting a certain version of GCC, with high enough
> optimization setting) will warn that i may be used without being set.
> Why? After all, it is only used if flag is true, and in that case, i
> *was* set. Well, the problem is that the compiler can't know that flag
> isn't changed in the middle of the function call, perhaps by another
> thread. Perhaps in the call to g(). But *I* know that it can't - this
> program is single-threaded, g() does nothing to the flag, and in fact
> "flag" is never changed after initialization.

Hmmm...

$ gcc -pedantic -O3 -Wall -Wextra -Werror test_flag.c test_flag1.c
$ cat test_flag1.c
int flag = 1;
$ gcc --version
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)

Looks like some gcc developer heard your rant ;-)

> >  * More importantly, I've seen countless such warnings (in numerous
> >    user-space programs). All of these were real bugs waiting to happen.
> 
> I agree, but I don't agree that programs with bugs should not be allowed
> to run. I'll tell you a dirty little secret: All programs, even good
> ones, have real bugs waiting to happen. Is this a reason not to allow
> users to compile them?

Allow? Sure they can (if they are developers, not users ;-)
They'll just need to edit out the '-Werror' from the build flags.

The extra work needed to make this workaround is a feature, not a bug.

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
...there are two types of command interfaces in the world of
             computing: good interfaces and user interfaces.
                            - Dan Bernstein, Author of qmail