Re: [PATCH] removal of "static foo = 0"

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Nov 28, 2000 at 10:55:06AM +0100, Andreas Schwab wrote:
> Alexander Viro <viro@math.psu.edu> writes:
> 
> |> On Tue, 28 Nov 2000, Andrea Arcangeli wrote:
> |> 
> |> > On Tue, Nov 28, 2000 at 12:10:33PM +0900, kumon@flab.fujitsu.co.jp wrote:
> |> > > If you have two files:
> |> > > test1.c:
> |> > > int a,b,c;
> |> > > 
> |> > > test2.c:
> |> > > int a,c;
> |> > > 
> |> > > Which is _stronger_?
> |> > 
> |> > Those won't link together as they aren't declared static.
> |> 
> |> Try it. They _will_ link together.
> 
> Not if you compile with -fno-common, which should actually be the default
> some day, IMHO.

I thought -fno-common was the default behaviour indeed, and I agree it should
become the default since current behaviour can lead to sublte bugs. (better I
discovered this gcc "extension" this way than after some day of debugging :)

I'm all for gcc extensions when they're powerful and useful, but this
one looks absolutely worthless. I don't see any advantage from the current
behaviour (avoid an "extern" in some include file that we have/want to write
anyways to write correct C code?), and at least in large project (like the
kernel) where different part of the project are handled by different people
using -fno-common is pretty much mandatory IMHO.

Think at somebody writing a driver starting from another driver, maybe
he renames most of the stuff but he forgets to rename an uninitialized
global variable. This bug won't trigger for him because he's not using
the other driver at the same time. It will trigger only when an unlucky
user will happen to use both drivers at the same time because he owns
both hardwares...

I disagree with GCC documentation:

`-fno-common'
     Allocate even uninitialized global variables in the bss section of
     the object file, rather than generating them as common blocks.
     This has the effect that if the same variable is declared (without
     `extern') in two different compilations, you will get an error
     when you link them.  The only reason this might be useful is if
			  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     you wish to verify that the program will work on other systems
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     which always work this way.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^

That's one reason, but it's really not the interesting one...

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/