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

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

[Werner Almesberger]

Adam J. Richter wrote:
> 	At the moment, I have started daydreaming about instead
> writing an "elf squeezer" to do this and other space optimizations
> by modifying objdump.

Hmm, this would require that gcc never calculates the location of an
explicitly initialized static variable based on the address of another
one. E.g. in

static int a = 0, b = 0, c = 0, d = 0;

...
    ... a+b+c+d ...
...

egcs-2.91.66 indeed doesn't seem to make this optimization on i386.
(Maybe the pointer increment or pointer offset solution would
actually be slower - didn't check.) But I'm not sure if this is also
true for other versions/architectures, or other code constructs.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
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/

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

[Adam J. Richter]

Michael Meissner wrote:
>On Sat, Nov 25, 2000 at 11:55:11PM +0000, Tim Waugh wrote:
>> On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:
>> 
>> > Which is silly. The variable is explicitly defined to be zero
>> > anyway, whether you put this in your code or not.
>> 
>> Why doesn't the compiler just leave out explicit zeros from the
>> 'initial data' segment then?  Seems like it ought to be tought to..
>
>Because sometimes it matters.  For example, in kernel mode (and certainly for
>embedded programs that I'm more familiar with), the kernel does go through and
>zero out the so called BSS segment, so that normally uninitialized static
>variables will follow the rules as laid out under the C standards (both C89 and
>C99).  I can imagine however, that the code that is executed before the BSS
>area is zeroed out needs to be extra careful in terms of statics that it
>references, and those must be hand initialized.

	Since that code is already careful to hand initialize what
it needs and explicitly zeroes the BSS, that sounds like an argument
that it *is* safe to change gcc to move data that is intialized to
all zeroes into bss, either as a compiler option or even not
optionally.

	I am not a gcc hacker, but it looks to me like one could
copy the code from output_constant and the functions that it
calls (in gcc-2.95.2/gcc/gcc/varasm.c) to walk the tree to figure
out if the data was all zeroes.  I even started writing a routine
for assemble_variable to call to try to test just for the integer case
(basically just by cutting and pasting code).  I include it here just
to illustrate.  Note: this code doesn't even type check properly when
I try to compile it, so I know it's very wrong, but it's as good as
posting pseudo code to explain my thinking).

void
clear_zero_initialization(tree decl)
{
        tree exp = DECL_INITIAL(decl);
        enum tree_code code;

        if (exp == NULL)
                return;

        code = TREE_CODE (TREE_TYPE (exp));
        if (lang_expand_constant)
                exp = (*lang_expand_constant) (exp);

        while ((TREE_CODE (exp) == NOP_EXPR
                && (TREE_TYPE (exp) == TREE_TYPE (TREE_OPERAND (exp, 0))
                    || AGGREGATE_TYPE_P (TREE_TYPE (exp))))
               || TREE_CODE (exp) == NON_LVALUE_EXPR)
                exp = TREE_OPERAND (exp, 0);

        if (code == INTEGER_TYPE && exp == const0_rtx)
                DECL_INITIAL(decl) = NULL;
}


	At the moment, I have started daydreaming about instead
writing an "elf squeezer" to do this and other space optimizations
by modifying objdump.  However, I do think that such an improvement
to gcc would be at least a bit useful to the larger user base than
just those people who use binutils-based systems.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."
-
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/

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

[David S. Miller]

   Date:   Mon, 27 Nov 2000 09:41:39 +0100
   From: Werner Almesberger <Werner.Almesberger@epfl.ch>

   egcs-2.91.66 indeed doesn't seem to make this optimization on i386.
   (Maybe the pointer increment or pointer offset solution would
   actually be slower - didn't check.) But I'm not sure if this is
   also true for other versions/architectures, or other code
   constructs.

There is no guarentee that contiguous data or bss section members
will appear contiguous and in the same order, in the final object.

In fact, a specific optimization done on MIPS and other platforms is
to place all data members under a certain size in a special
".small.data" section.  So for example:

static int a;
static struct foo b;
static int b;

Would not place 'b' at "&a + sizeof(a) + sizeof(b)"

Also I believe linkers are allowed to arbitrarily reorder members in
the data and bss sections.  I could be wrong on this one though.

Later,
David S. Miller
davem@redhat.com
-
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/

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

[Werner Almesberger]

David S. Miller wrote:
> There is no guarentee that contiguous data or bss section members
> will appear contiguous and in the same order, in the final object.

That's a different issue and actually okay in this case.

What I meant to show is an example where the compiler happens to
allocate the variables in sequence, and where it could access them
either by referencing each by absolute address, with relocation (so
that objdump-patcher could change that), or by generating a pointer
and using pointer-relative addressing or pointer increment (so we
only get one relocation and never know what may go wrong with the
other variables).

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
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/

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

[Andrea Arcangeli]

On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> Also I believe linkers are allowed to arbitrarily reorder members in
> the data and bss sections.  I could be wrong on this one though.

I'm not sure either, but we certainly rely on that behaviour somewhere.
Just to make an example fs/dquot.c:

	int nr_dquots, nr_free_dquots;

kernel/sysctl.c:

	{FS_NRDQUOT, "dquot-nr", &nr_dquots, 2*sizeof(int),

The above is ok also on mips in practice though.

In 2.2.x there was more of them.

Regardless if we're allowed to rely on the ordering the above is bad coding
practice because somebody could forget about the dependency on the ordering and
put something between nr_dquotes and nr_free_dquotes :), so such dependency
should be avoided anyways...

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/

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

[Michael Meissner]

On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
> On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > Also I believe linkers are allowed to arbitrarily reorder members in
> > the data and bss sections.  I could be wrong on this one though.
> 
> I'm not sure either, but we certainly rely on that behaviour somewhere.
> Just to make an example fs/dquot.c:
> 
> 	int nr_dquots, nr_free_dquots;
> 
> kernel/sysctl.c:
> 
> 	{FS_NRDQUOT, "dquot-nr", &nr_dquots, 2*sizeof(int),
> 
> The above is ok also on mips in practice though.

That needs to be fixed ASAP to use an array (not a structure).  It is simply
wrong to depend on two variables winding up in at adjacent offsets.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

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

[Andrea Arcangeli]

On Mon, Nov 27, 2000 at 12:36:55PM -0500, Michael Meissner wrote:
> wrong to depend on two variables winding up in at adjacent offsets.

I'd like if it will be written explicitly in the specs that it's forbidden to
rely on that. I grepped the specs and I didn't find anything. So I wasn't sure
if I missed the information in the specs or not. I never investigated on it
because I always considered it bad coding regardless the fact it's guaranteed
to generate the right asm with the _current_ tools.

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/

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

[Richard B. Johnson]

On Mon, 27 Nov 2000, Andrea Arcangeli wrote:

> On Mon, Nov 27, 2000 at 12:36:55PM -0500, Michael Meissner wrote:
> > wrong to depend on two variables winding up in at adjacent offsets.
> 
> I'd like if it will be written explicitly in the specs that it's forbidden to
> rely on that. I grepped the specs and I didn't find anything. So I wasn't sure
> if I missed the information in the specs or not. I never investigated on it
> because I always considered it bad coding regardless the fact it's guaranteed
> to generate the right asm with the _current_ tools.
> 
> Andrea
> -

The following shell-script shows that gcc-2.8.1 produces code with
data allocations adjacent. However, they are reversed!


cat - <<EOF >x.c
int a, b;
EOF
gcc -c -o x.o x.c
cat - <<EOF >y.c
extern int a;
extern int b;
int main() {
printf("a=%p\n", &a);
printf("b=%p\n", &b);
return 0;
}
EOF
gcc -o y y.c x.o
./y

a=0x804a42c
b=0x804a428

The output shows variable 'a' as being in the higher address.
So, it's not good to assume anything about so-called adjacent
variables.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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/

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

[Andrea Arcangeli]

On Mon, Nov 27, 2000 at 02:34:45PM -0500, Richard B. Johnson wrote:
> The following shell-script shows that gcc-2.8.1 produces code with
> data allocations adjacent. However, they are reversed!

same with 2.95.* :).

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/

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

[Horst von Brand]

Andrea Arcangeli <andrea@suse.de> said:
> On Mon, Nov 27, 2000 at 02:34:45PM -0500, Richard B. Johnson wrote:
> > The following shell-script shows that gcc-2.8.1 produces code with
> > data allocations adjacent. However, they are reversed!

> same with 2.95.* :).

The point was if gcc did use the fact that variables are adyacent in memory
to generate better code, and this degenerated into the current discussion
about where they are from the programmers perspective.

- If gcc is going to use the fact that some variables are nearby for some
  optimization purposes, I do trust the gcc hackers to set stuff up so that
  they use it for variables that are nearby in VM, not just where defined
  together. If variables defined together end up adyacent or not is
  completely irrelevant. The compiler might even rearrange them to
  optimize for the access pattern observed.
- As a C programmer, you are only entitled to assume that pieces of the
  same object (array or struct) are laid out in memory in the order
  given. With segmented VM different objects would probably end up in
  different segments anyway.
--
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513  
  
-
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/

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

[Marcus Sundberg]

meissner@spectacle-pond.org (Michael Meissner) writes:

> On Mon, Nov 27, 2000 at 06:21:13PM +0100, Andrea Arcangeli wrote:
> > On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > > Also I believe linkers are allowed to arbitrarily reorder members in
> > > the data and bss sections.  I could be wrong on this one though.
> > 
> > I'm not sure either, but we certainly rely on that behaviour somewhere.
> > Just to make an example fs/dquot.c:
> > 
> > 	int nr_dquots, nr_free_dquots;
> > 
> > kernel/sysctl.c:
> > 
> > 	{FS_NRDQUOT, "dquot-nr", &nr_dquots, 2*sizeof(int),
> > 
> > The above is ok also on mips in practice though.
> 
> That needs to be fixed ASAP to use an array (not a structure).  It is simply
> wrong to depend on two variables winding up in at adjacent offsets.

This reminded me of an old bug which apparently still hasn't been
fixed (not in 2.2 at least). In init/main.c we have:

extern int rd_image_start;	/* starting block # of image */
#ifdef CONFIG_BLK_DEV_INITRD
kdev_t real_root_dev;
#endif
#endif

int root_mountflags = MS_RDONLY;

and then in kernel/sysctl.c:

#ifdef CONFIG_BLK_DEV_INITRD
	{KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int),
	 0644, NULL, &proc_dointvec},
#endif

Because rd_image_start and root_mountflags are both int-aligned,
this happens to work on little endian platforms. On big endian
platforms however writing a value in the range 0-65535 to 
/proc/sys/kernel/real-root-dev will place 0 in real_root_dev,
and the actual value in the two padding bytes...

(Yes, I'm one of the few that have actually used this feature. ;-)

Unfortunately proc_dointvec() doesn't support shorts, so what is
the correct fix? Changing:
kdev_t real_root_dev;
into
int real_root-dev;
is a perfectly working solution, but is it acceptable?

//Marcus
-- 
-------------------------------+-----------------------------------
        Marcus Sundberg        |       Phone: +46 707 452062
  Embedded Systems Consultant  |      Email: marcus@cendio.se
       Cendio Systems AB       |       http://www.cendio.com
-
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/

Re: real_root_dev

[Andries Brouwer]

On Mon, Nov 27, 2000 at 10:27:00PM +0100, Marcus Sundberg wrote:

> This reminded me of an old bug which apparently still hasn't been
> fixed (not in 2.2 at least). In init/main.c we have:
> 
> extern int rd_image_start;	/* starting block # of image */
> #ifdef CONFIG_BLK_DEV_INITRD
> kdev_t real_root_dev;
> #endif
> #endif
> 
> int root_mountflags = MS_RDONLY;
> 
> and then in kernel/sysctl.c:
> 
> #ifdef CONFIG_BLK_DEV_INITRD
> 	{KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int),
> 	 0644, NULL, &proc_dointvec},
> #endif
> 
> Because rd_image_start and root_mountflags are both int-aligned,
> this happens to work on little endian platforms. On big endian
> platforms however writing a value in the range 0-65535 to 
> /proc/sys/kernel/real-root-dev will place 0 in real_root_dev,
> and the actual value in the two padding bytes...
> 
> Unfortunately proc_dointvec() doesn't support shorts, so what is
> the correct fix? Changing:
> kdev_t real_root_dev;
> into
> int real_root-dev;
> is a perfectly working solution, but is it acceptable?

If you compile the kernel and use an integral type for kdev_t, perhaps.
On the other hand, I usually use a pointer type for kdev_t, and then
this entire sysctl construction is broken.

Andries
-
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/

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

[kumon]

Andrea Arcangeli writes:
 > I'd like if it will be written explicitly in the specs that it's forbidden to
 > rely on that. I grepped the specs and I didn't find anything. So I wasn't sure
 > if I missed the information in the specs or not. I never investigated on it

If you have two files:
test1.c:
int a,b,c;

test2.c:
int a,c;

Which is _stronger_?


If somebody adds such a file to the kernel tree, the layout is changed
by link orderling, irrelevant option on/off or other magical
environments. Spec doesn't say anything about the layout of the
variables.

--
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
-
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/

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

[Andrea Arcangeli]

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.

If they would been static they could be ordered file-per-file (note: I'm not
suggesting anything like that and I'm more than happy the compiler is allowed
to do sane optimizations with none downside :).

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/

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

[Alexander Viro]

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.

-
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/

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

[Michael Meissner]

On Mon, Nov 27, 2000 at 10:35:45PM -0500, Alexander Viro wrote:
> 
> 
> 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.

This is a GCC extension (actually it is a pretty common UNIX extension, but the
official standard says you can only have one definition of a global variable).

Off the top of my head, here are some reasons variables could be put in
different orders:

   1)	The compilation system has the concept of a small data pointer, which
	is a register that is assumed by the compiler to point to a small
	region of memory (it is never allocated by the compiler and setup in
	the initialization modules).  The compiler decides to put some
	variables into the small data region and other variables outside of
	it.  Typically the choice is based on size of the variable.  Small data
	pointers are typically used when the machine has plenty of registers
	and it takes 2 or more instructions to build the address of a random
	variable in memory with load high/load low type instructions, and the
	small data pointer has the upper half already loaded, and uses special
	relocations to access the variable based off of the difference of a
	special symbol.

   2)	Even without a small data pointer, a compiler might decide to sort the
	variables emitted based on either size or number of accesses to take
	advantage of instructions with smaller offsets.

   3)	The above mentioned global, non-initialized variables (ie, the
	so-called 'common' variables).  Where the linker puts the variables
	into the bss section in any order it chooses.  For example, the VMS
	linker used to sort common variables alphabetically.

   4)	For static variables, the compilation system might decide to omit the
	variable until it sees a reference to the variable, and if the first
	variable is referenced in one function, and the second is referenced
	several functions later.

   5)	At some point in the future, on machines with many more registers than
	the normal 32, the linker might see all references to a variable, and
	decide to put it in a static register rather than memory.

   6)	A checkout compiler could randomly order things specifically to catch
	these type of errors (the problem with the normal checkout compilers
	that I'm aware of, is that the kernel uses structs to talk to real
	devices and interact with system calls with fixed layouts).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

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

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
-
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/

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

[Andrea Arcangeli]

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/

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

[Andreas Schwab]

Andrea Arcangeli <andrea@suse.de> writes:

|> 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 :)

This is not really a gcc extension, but long Unix tradition.  If you make
-fno-common the default then many programs will not build any more,
including the Linux kernel. :-)

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
-
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/

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

[Andrea Arcangeli]

On Tue, Nov 28, 2000 at 05:09:48PM +0100, Andreas Schwab wrote:
> including the Linux kernel. :-)

As it's a worthless extension it's always trivial to fixup after its removal :).

The fixup also shown that the sis_300 and sis_301 driver would break if used at
the same time (probably unlikely to happen as they're FB drivers though).

This patch compiles 2.4.0-test12-pre2 with -fno-common and it fixups some minor
compilation problem around the kernel. Karsten note the lc_start_delay_check
change I did to make it to compile, it's not implemented yet, it only compiles
right now.

Patch is verified to compile with almost everything linked into the kernel, and
it boots with my normal configuration.

--- 2.4.0-test12-pre2-fno-common/drivers/char/applicom.c.~1~	Thu Jul 13 06:58:42 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/char/applicom.c	Tue Nov 28 19:07:05 2000
@@ -63,8 +63,8 @@
 #define PCI_DEVICE_ID_APPLICOM_PCIGENERIC     0x0001
 #define PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN 0x0002
 #define PCI_DEVICE_ID_APPLICOM_PCI2000PFB     0x0003
-#define MAX_PCI_DEVICE_NUM 3
 #endif
+#define MAX_PCI_DEVICE_NUM 3
 
 static char *applicom_pci_devnames[] = {
 	"PCI board",
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.c.~1~	Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/isdnl3.c	Tue Nov 28 19:46:08 2000
@@ -522,6 +522,11 @@
 	l3ml3p(st, DL_RELEASE | CONFIRM);
 }
 
+static void
+lc_start_delay_check(struct FsmInst *fi, int event, void *arg)
+{
+	/* FIXME */
+}
 
 /* *INDENT-OFF* */
 static struct FsmNode L3FnList[] __initdata =
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c.~1~	Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_s.c	Tue Nov 28 19:47:21 2000
@@ -75,7 +75,7 @@
 			(cs->hw.njet.last_is0 & NETJET_IRQM0_READ))
 			/* we have a read dma int */
 			read_tiger(cs);
-		if (cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
+		if ((cs->hw.njet.irqstat0 & NETJET_IRQM0_WRITE) !=
 			(cs->hw.njet.last_is0 & NETJET_IRQM0_WRITE))
 			/* we have a write dma int */
 			write_tiger(cs);
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c.~1~	Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/nj_u.c	Tue Nov 28 19:48:52 2000
@@ -11,6 +11,7 @@
 #include <linux/pci.h>
 #include <linux/interrupt.h>
 #include <linux/ppp_defs.h>
+#include <linux/init.h>
 #include "netjet.h"
 
 const char *NETjet_U_revision = "$Revision: 2.8 $";
@@ -131,7 +132,7 @@
 	return(0);
 }
 
-static struct pci_dev *dev_netjet __initdata;
+static struct pci_dev *dev_netjet __initdata = 0;
 
 int __init
 setup_netjet_u(struct IsdnCard *card)
--- 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.c.~1~	Tue Nov 28 18:40:29 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/isdn/hisax/config.c	Tue Nov 28 20:04:59 2000
@@ -376,7 +376,7 @@
 #endif /* IO0_IO1 */
 #endif /* MODULE */
 
-static int nrcards;
+int nrcards;
 
 extern char *l1_revision;
 extern char *l2_revision;
--- 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h.~1~	Tue Nov 28 18:50:21 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/media/video/bttv.h	Tue Nov 28 18:51:19 2000
@@ -179,9 +179,9 @@
 
 /* i2c */
 #define I2C_CLIENTS_MAX 8
-struct i2c_algo_bit_data bttv_i2c_algo_template;
-struct i2c_adapter bttv_i2c_adap_template;
-struct i2c_client bttv_i2c_client_template;
+extern struct i2c_algo_bit_data bttv_i2c_algo_template;
+extern struct i2c_adapter bttv_i2c_adap_template;
+extern struct i2c_client bttv_i2c_client_template;
 void bttv_bit_setscl(void *data, int state);
 void bttv_bit_setsda(void *data, int state);
 void bttv_call_i2c_clients(struct bttv *btv, unsigned int cmd, void *arg);
--- 2.4.0-test12-pre2-fno-common/drivers/net/arlan.h.~1~	Tue Nov 28 19:10:06 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/net/arlan.h	Tue Nov 28 19:11:44 2000
@@ -321,7 +321,7 @@
       int tx_queue_len;
 };
 
-struct arlan_conf_stru arlan_conf[MAX_ARLANS];
+extern struct arlan_conf_stru arlan_conf[MAX_ARLANS];
 
 struct TxParam
 {
--- 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h.~1~	Tue Nov 28 19:25:37 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/usb/storage/usb.h	Tue Nov 28 19:40:11 2000
@@ -187,7 +187,7 @@
 extern struct semaphore us_list_semaphore;
 
 /* The structure which defines our driver */
-struct usb_driver usb_storage_driver;
+extern struct usb_driver usb_storage_driver;
 
 /* Function to fill an inquiry response. See usb.c for details */
 extern void fill_inquiry_response(struct us_data *us,
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.h.~1~	Tue Nov 28 18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.h	Tue Nov 28 19:28:42 2000
@@ -95,15 +95,6 @@
 
 #endif
 
-USHORT      P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
-USHORT	 CRT1VCLKLen; //VCLKData table length of bytes of each entry
-USHORT   flag_clearbuffer; //0: no clear frame buffer 1:clear frame buffer
-int      RAMType;
-int      ModeIDOffset,StandTable,CRT1Table,ScreenOffset,VCLKData,MCLKData, ECLKData;
-int      REFIndex,ModeType;
-USHORT	 IF_DEF_LVDS,IF_DEF_TRUMPION;
-USHORT   VBInfo,LCDResInfo,LCDTypeInfo,LCDInfo;
-
 //int    init300(int,int,int);
 VOID   SetMemoryClock(ULONG);
 VOID   SetDRAMSize(PHW_DEVICE_EXTENSION);
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_301.c.~1~	Tue Nov 28 18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_301.c	Tue Nov 28 19:39:25 2000
@@ -3,6 +3,14 @@
 #include <linux/config.h>
 #include "sis_301.h"
 
+static USHORT   P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
+static USHORT	flag_clearbuffer; //0:no clear frame buffer 1:clear frame buffer
+static int      RAMType;
+static int      ModeIDOffset,StandTable,CRT1Table,ScreenOffset,VCLKData,MCLKData, ECLKData;
+static int      REFIndex,ModeType;
+static USHORT VBInfo,LCDResInfo,LCDTypeInfo,LCDInfo;
+static USHORT	 IF_DEF_LVDS,IF_DEF_TRUMPION;
+
 #ifndef CONFIG_FB_SIS_LINUXBIOS
 
 BOOLEAN SetCRT2Group(USHORT BaseAddr,ULONG ROMAddr,USHORT ModeNo,
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.c.~1~	Tue Nov 28 18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_300.c	Tue Nov 28 19:29:04 2000
@@ -7,6 +7,14 @@
 #pragma alloc_text(PAGE,SiSInit300)
 #endif
 
+static USHORT      P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
+static USHORT	 CRT1VCLKLen; //VCLKData table length of bytes of each entry
+static USHORT   flag_clearbuffer; //0: no clear frame buffer 1:clear frame buffer
+static int      RAMType;
+static int      ModeIDOffset,StandTable,CRT1Table,ScreenOffset,VCLKData,MCLKData, ECLKData;
+static int      REFIndex,ModeType;
+static USHORT	 IF_DEF_LVDS,IF_DEF_TRUMPION;
+static USHORT   VBInfo,LCDResInfo,LCDTypeInfo,LCDInfo;
 
 #ifdef NOBIOS
 BOOLEAN SiSInit300(PHW_DEVICE_EXTENSION HwDeviceExtension)
--- 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_301.h.~1~	Tue Nov 28 18:40:01 2000
+++ 2.4.0-test12-pre2-fno-common/drivers/video/sis/sis_301.h	Tue Nov 28 19:31:11 2000
@@ -3,7 +3,6 @@
 
 USHORT SetFlag,RVBHCFACT,RVBHCMAX,VGAVT,VGAHT,VT,HT,VGAVDE,VGAHDE;
 USHORT VDE,HDE,RVBHRS,NewFlickerMode,RY1COE,RY2COE,RY3COE,RY4COE;                
-;USHORT LCDResInfo,LCDTypeInfo,LCDInfo;
 USHORT VCLKLen;
 USHORT LCDHDES,LCDVDES;
 
@@ -180,14 +179,6 @@
 extern USHORT CGA_DAC[];
 extern USHORT EGA_DAC[];
 extern USHORT VGA_DAC[];
-
-extern USHORT   P3c4,P3d4,P3c0,P3ce,P3c2,P3ca,P3c6,P3c7,P3c8,P3c9,P3da;
-extern USHORT	flag_clearbuffer; //0:no clear frame buffer 1:clear frame buffer
-extern int      RAMType;
-extern int      ModeIDOffset,StandTable,CRT1Table,ScreenOffset,VCLKData,MCLKData, ECLKData;
-extern int      REFIndex,ModeType;
-extern USHORT VBInfo,LCDResInfo,LCDTypeInfo,LCDInfo;
-extern USHORT	 IF_DEF_LVDS,IF_DEF_TRUMPION;
 
 extern VOID     SetMemoryClock(ULONG);
 extern VOID     SetDRAMSize(PHW_DEVICE_EXTENSION);
--- 2.4.0-test12-pre2-fno-common/include/linux/vt_kern.h.~1~	Tue Nov 28 18:44:22 2000
+++ 2.4.0-test12-pre2-fno-common/include/linux/vt_kern.h	Tue Nov 28 18:46:26 2000
@@ -30,7 +30,7 @@
 	wait_queue_head_t paste_wait;
 } *vt_cons[MAX_NR_CONSOLES];
 
-void (*kd_mksound)(unsigned int hz, unsigned int ticks);
+extern void (*kd_mksound)(unsigned int hz, unsigned int ticks);
 
 /* console.c */
 
--- 2.4.0-test12-pre2-fno-common/include/linux/if_frad.h.~1~	Tue Nov 28 19:08:18 2000
+++ 2.4.0-test12-pre2-fno-common/include/linux/if_frad.h	Tue Nov 28 19:09:01 2000
@@ -192,7 +192,7 @@
 int register_frad(const char *name);
 int unregister_frad(const char *name);
 
-int (*dlci_ioctl_hook)(unsigned int, void *);
+extern int (*dlci_ioctl_hook)(unsigned int, void *);
 
 #endif __KERNEL__
 
--- 2.4.0-test12-pre2-fno-common/net/atm/lec.h.~1~	Tue Nov 28 20:01:59 2000
+++ 2.4.0-test12-pre2-fno-common/net/atm/lec.h	Tue Nov 28 20:02:45 2000
@@ -16,9 +16,9 @@
 
 #if defined (CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE)
 #include <linux/if_bridge.h>
-struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br,
+extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br,
                                                 unsigned char *addr);
-void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent);
+extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent);
 #endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */
 
 #define LEC_HEADER_LEN 16
--- 2.4.0-test12-pre2-fno-common/net/bridge/br_private.h.~1~	Tue Nov 28 19:57:02 2000
+++ 2.4.0-test12-pre2-fno-common/net/bridge/br_private.h	Tue Nov 28 19:59:43 2000
@@ -112,8 +112,8 @@
 	int				gc_interval;
 };
 
-struct notifier_block br_device_notifier;
-unsigned char bridge_ula[6];
+extern struct notifier_block br_device_notifier;
+extern unsigned char bridge_ula[6];
 
 /* br.c */
 void br_dec_use_count(void);
--- 2.4.0-test12-pre2-fno-common/Makefile.~1~	Tue Nov 28 18:40:28 2000
+++ 2.4.0-test12-pre2-fno-common/Makefile	Tue Nov 28 18:42:50 2000
@@ -16,7 +16,7 @@
 FINDHPATH	= $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
 
 HOSTCC  	= gcc
-HOSTCFLAGS	= -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS	= -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-common
 
 CROSS_COMPILE 	=
 
@@ -87,7 +87,7 @@
 
 CPPFLAGS := -D__KERNEL__ -I$(HPATH)
 
-CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
+CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
 AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
 
 #



I'd suggest to include it into 2.4 until -fno-common will become the default in
gcc.

Patch is here too:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test12-pre2/gcc-fno-common-1

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/

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

[Michael Meissner]

On Tue, Nov 28, 2000 at 04:16:12PM +0100, Andrea Arcangeli wrote:
> 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.

Umm, the original Ritchie C compiler on the PDP-11 and the Johnson 'Portable' C
compiler both had this extension, as well as every other C compiler under UNIX
(tm) I've ever used or read the documentation for.  It is also mentioned in the
standards as a common extension (I wrote the initial draft for this section in
the C89 standard).  When asked why the disconnect between what K&R said
(ref/def model) and what their compilers actually did (common model), the AT&T
representative at the time said that the ref/def model was put into K&R when
they tried to make a C compiler for their IBM mainframes, using the standard
linker, and discovered that linker would page align each common variable (CSECT
in IBM terminology IIRC).  The IBM linker is also the reason why the K&R and
the C89 standard had the rule that global names must be unique to 6 characters,
one case (which is another extension that just about everybody has and depends
on).

The default for C++ is -fno-common.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

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

[Richard B. Johnson]

On Mon, 27 Nov 2000, Andrea Arcangeli wrote:

> On Mon, Nov 27, 2000 at 12:39:55AM -0800, David S. Miller wrote:
> > Also I believe linkers are allowed to arbitrarily reorder members in
> > the data and bss sections.  I could be wrong on this one though.
> 
> I'm not sure either, but we certainly rely on that behaviour somewhere.
> Just to make an example fs/dquot.c:
> 
> 	int nr_dquots, nr_free_dquots;
> 
> kernel/sysctl.c:
> 
> 	{FS_NRDQUOT, "dquot-nr", &nr_dquots, 2*sizeof(int),
> 
> The above is ok also on mips in practice though.
> 

This code is simply wrong! You can't assume that the declaration of
two variables, no matter how similar, makes them adjacent in
memory! You also can't assume any order. We have good 'C' compilers
that do order things as we assume, however it is only fortuitous, and
not defined any any rule(s).


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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/

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

[Michael Meissner]

On Mon, Nov 27, 2000 at 09:41:39AM +0100, Werner Almesberger wrote:
> Adam J. Richter wrote:
> > 	At the moment, I have started daydreaming about instead
> > writing an "elf squeezer" to do this and other space optimizations
> > by modifying objdump.
> 
> Hmm, this would require that gcc never calculates the location of an
> explicitly initialized static variable based on the address of another
> one. E.g. in
> 
> static int a = 0, b = 0, c = 0, d = 0;
> 
> ...
>     ... a+b+c+d ...
> ...
> 
> egcs-2.91.66 indeed doesn't seem to make this optimization on i386.
> (Maybe the pointer increment or pointer offset solution would
> actually be slower - didn't check.) But I'm not sure if this is also
> true for other versions/architectures, or other code constructs.

Jeff Law played with a similar optimization about 1-2 years ago, and eventually
deleted all of the code because there were problems with the code.  It would
help some of our platforms (but not the x86) to access all variables in the
same section via a common pointer.  This is because on those systems, it often
times takes 2-3 instructions to access global/static variables.  Global
variables you have more problems visiblity and such.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

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

[Elmer Joandi]

Nice to see again a two cutting-edge-killing opinions.

Every time I really wonder, how such brilliant hackers can be that stupid
that they can not have cake and eat it the same time, and have to scratch
each-others eyes every time.

Use macros.

Kernel has become so big that it really needs universal  debugging macros
instead of comments. Comments are waste of brain&fingerpower, if the same
can be explained by long variable names and debug macros.

static Subsystem_module_LocalVariableForThisPurpose;

int Subsytem_module_function_this_and_that(){
	DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
	DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
}


Those macros would be acceptable if they are unified and taken to
kernel configuration level, so it would be easy to switch them in/out 
not only as boolean option but systematically for different levels,
subsystems and modules.

elmer.


-
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/

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

[Alexander Viro]

On Sun, 26 Nov 2000, Elmer Joandi wrote:

> 
> Kernel has become so big that it really needs universal  debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
> 
> static Subsystem_module_LocalVariableForThisPurpose;
> 
> int Subsytem_module_function_this_and_that(){
> 	DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
> 	DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
> }

I would suggest you to read through the following book and files:
	* Kernighan & Pike, "The Practice of Programming"
	* Documentation/CodingStyle
	* drivers/net/aironet4500_proc.c
and consider, erm, discrepancies. On the second thought, reading K&R
might also be useful. IOW, no offense, but your C is bad beyond belief.

-
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/

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

[Elmer Joandi]

On Sun, 26 Nov 2000, Alexander Viro wrote:

> I would suggest you to read through the following book and files:
> 	* Kernighan & Pike, "The Practice of Programming"
> 	* Documentation/CodingStyle
> 	* drivers/net/aironet4500_proc.c
> and consider, erm, discrepancies. On the second thought, reading K&R
> might also be useful. IOW, no offense, but your C is bad beyond belief.

Yep, very true.
aironet4500_proc.c is ugly. And is because there is quickly handwirtten
something that should have been generic for kernel for some long time, not
for every driver-writer to reinvent a wheel.
Note that there is something that virtually elliminates need for
exact user<->kernel level interfaces and userlevel kerneldata manipulation 
programs and lots of other maintenance pains.
And it does it in quite short sentences. Plus, half of that file is direct
repeating of some non-exported kernel functions. But, if you think you can
do better, then look into aironet4500_rid.c and handcode it (like real K&R
people do), instead of using aironet4500_proc.c to operate on it.
Also, pcmcia/aironet4500_cs.c has lots of ugly parts. Those which are
related to stupid masohistic code repetitions due to pcmcia package
interface being "cutting edge optimal stupid"

The same true is that 2.4 kernel is, in commercial production sense, late
for 6 months. And reason being that the codebase and testing becomes
unmanageable. And it becomes unmanageable, because some people only read
K&R and try to optimize last bit out of it with using and old book.

I'd really propose again:
1. universal debug macros
2. universalt user-kernelspace configuration interface via proc/sys

I'd really like C++, but it can be done with C and macros.
Some years ago I even managed to write something like stl container 
withing C and with macros. That was really screwy thing.

elmer.


-
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/

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

[Rogier Wolff]

Elmer Joandi wrote:
> 
> Nice to see again a two cutting-edge-killing opinions.
> 
> Every time I really wonder, how such brilliant hackers can be that stupid
> that they can not have cake and eat it the same time, and have to scratch
> each-others eyes every time.
> 
> Use macros.
> 
> Kernel has become so big that it really needs universal  debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
> 
> static Subsystem_module_LocalVariableForThisPurpose;
> 
> int Subsytem_module_function_this_and_that(){
> 	DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
> 	DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != NULL )
> }
> 
> 
> Those macros would be acceptable if they are unified and taken to
> kernel configuration level, so it would be easy to switch them in/out 
> not only as boolean option but systematically for different levels,
> subsystems and modules.

I leave "debugging" enabled in the drivers I submit. This allows me to
tell customers who are having "It won't detect my card" problems to
enable the debugging output. Most of the time this leads to a resolution
within minutes of me getting the debugging output log. 

Sure it will slow the driver down a bit, because of all those bit-test
instructions in the driver. If it bothers you, you get to turn it
off. If you are capable of that, you are also capable enough to turn
it back on when neccesary.

The debug asserts that trigger during normal operation are what make
the Linux kernel stable. Problems get spotted at an early
stage. Problems get fixed. Microsoft disables all debugging before
shipping stuff. That means they don't get useful bugreports from the
field ("When I do this, the system sometimes locks...." compared to
"my system crashes with: 'panic: sk buff underrun at 0xc0123456'"). 

This was discussed and a decision was taken that we're on the good
track around 5 years ago. I guess that there is some new blood to be
convinced nowadays...

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

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

[Adam J. Richter]

	Is there some reason why gcc does not put static data that
is explicitly initialized to zero in .bss?  If not, then fixing
gcc would provide more space savings than these patches, and
improve more software than just the Linux kernel.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."
-
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/

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

[Andries Brouwer]

On Sat, Nov 25, 2000 at 11:50:20AM +0000, Russell King wrote:
> Rusty Russell writes:
> > What irritates about these monkey-see-monkey-do patches is that if I
> > initialize a variable to NULL, it's because my code actually relies on
> > it; I don't want that information eliminated.
> 
> What information is lost?  Unless you're working on a really strange
> machine which does not zero bss, the following means the same from the
> codes point of view:
> 
> static int foo = 0;
> static int foo;
> 
> Both are initialised to zero by the time the code sees them for the
> first time.  Therefore there is no difference to the code in its reliance
> on whether foo is zero.  foo will be zero in both cases.
> 
> Also, any good programmer worth their skin should know this, and should
> realise it.  Therefore, there is no information loss

What a strange reaction. If I write

 static int foo;

this means that foo is a variable, local to the present compilation unit,
whose initial value is irrelevant because it will be assigned to before use.
If I write

 static int foo = 0;

this means that the code depends on the initialization.
Indeed, it is customary to write

 int foo = 0;  /* just for gcc */

when the initialization in fact is not necessary.


It is a bad programming habit to depend on this zero initialization.
Indeed, very often, when you have a program that does something
you need to change it so that it does that thing a number of times.
Well, put a for- or while-loop around it. But wait! The second time
through the loop certain variables need to be reinitialized. Which ones?
The ones that were initialized explicitly in your first program.
Make the program into a function in a larger one. Same story.


Saving a byte in the binary image is not very interesting.
Preserving information about the program is important.

I see that this message is cc'ed to Tigran, so let me address him as well.
Tigran, you like to destabilize Linux. I like to stabilize Linux.

If it is your intention to destabilize then you need not read the following.
But let us assume that you try to make a perfect system.

There is the issue of local and global correctness.
A piece of code is locally correct when its correctness can be seen
by just looking at those lines, or that function, or that source file.
A piece of code is globally correct when you need to read the entire kernel
source to convince yourself that all is well.

Often local correctness is obtained by local tests. After reading the entire
kernel source you conclude that these tests are superfluous because they
are satisfied in all cases. And you think it is an improvement to remove
the test. It almost never is. On a fast path, where every cycle counts, yes.
But it is not a good idea to sacrifice local correctness and save five
kernel image bytes, or speed up the mount system call by 0.001%.
Why not? Because you read the entire kernel source of today.
But not that of next week. Somewhere someone changes some code.
The test is gone and the kernel crashes instead of returning an error.

You even like to destabilize when there is no gain in size or speed at all.
It is bad coding practice to use casts. They tell the compiler not to check.
With functions returning (void *) the opposite is true. The compiler cannot
check now, but given a cast, it can. Thus, I wrote a few months ago

> If one just writes
>       foo = kmalloc(n * sizeof(some_type), GFP_x);
> then neither the compiler nor the human eye can check
> easily that things are right, i.e. that foo really is
> a (some_type *). Therefore it is better to write
>       foo = (some_type *) kmalloc(n * sizeof(some_type), GFP_x);

To my surprise you answered

: It is a small thing, Andries, but I still think otherwise than you.
: It is better for code to be smaller than to be slightly more fool-proof.

Please change your mind.

Andries

-
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/

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

[Russell King]

Andries Brouwer writes:
> What a strange reaction. If I write
> 
>  static int foo;
> 
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.

Wrong.  The initial value is well-defined.  Go and read any C standard you
choose.  Any C standard you care.  You will find out something really
interesting.  I can guarantee that you will find out that it will be
initialised to zero.  Unconditionally.  No question.  Absolutely.

> It is a bad programming habit to depend on this zero initialization.

Why?  Again, it is WELL defined, and is WELL defined in any C standard.

> Indeed, very often, when you have a program that does something
> you need to change it so that it does that thing a number of times.
> Well, put a for- or while-loop around it. But wait! The second time
> through the loop certain variables need to be reinitialized. Which ones?
> The ones that were initialized explicitly in your first program.
> Make the program into a function in a larger one. Same story.

Your point here is as clear as mud.

> If it is your intention to destabilize then you need not read the following.
> But let us assume that you try to make a perfect system.

There is absolutely NO destabilisation going on here.  Get a grip, read the
C standards, read the C startup code.  Then come back with something more
relevent.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
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/

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

[Andries Brouwer]

On Sat, Nov 25, 2000 at 09:07:08PM +0000, Russell King wrote:
> Andries Brouwer writes:
> > What a strange reaction. If I write
> > 
> >  static int foo;
> > 
> > this means that foo is a variable, local to the present compilation unit,
> > whose initial value is irrelevant 
> 
> Wrong.  The initial value is well-defined.

Oh, please - something is wrong with your reading comprehension.
Don't you understand the word "irrelevant"? It means that the
initial value does not matter. It does not mean undefined.
Please reread my letter and comment when you understand my point.
-
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/

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

[Russell King]

Andries Brouwer writes:
> Oh, please - something is wrong with your reading comprehension.
> Don't you understand the word "irrelevant"? It means that the
> initial value does not matter. It does not mean undefined.
> Please reread my letter and comment when you understand my point.

So now you try personnal insult to get your non-point across?

There is no more discussion to be had; this has rapidly decended into
yet another flaming match which I do not want to continue.  Please
decist, and we'll all keep our opinions to ourselves on this matter, ok?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
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/

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

[Herbert Xu]

Andries Brouwer <aeb@veritas.com> wrote:
>
>  int foo = 0;  /* just for gcc */

> when the initialization in fact is not necessary.

Only for non-static foo.

> It is a bad programming habit to depend on this zero initialization.
> Indeed, very often, when you have a program that does something
> you need to change it so that it does that thing a number of times.
> Well, put a for- or while-loop around it. But wait! The second time
> through the loop certain variables need to be reinitialized. Which ones?
> The ones that were initialized explicitly in your first program.
> Make the program into a function in a larger one. Same story.

Again, this only applies to non-static variables.  For static ones, they're
initialised once only even when they go out of scope.

> Saving a byte in the binary image is not very interesting.
> Preserving information about the program is important.

No information is lost.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/

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

[Andries Brouwer]

On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:

> No information is lost.

Do I explain things so badly? Let me try again.
The difference between

  static int a;

and

  static int a = 0;

is the " = 0". The compiler may well generate the same code,
but I am not talking about the compiler. I am talking about
the programmer. This " = 0" means (to me, the programmer)
that the correctness of my program depends on this initialization.
Its absense means (to me) that it does not matter what initial
value the variable has.

This is a useful distinction. It means that if the program

  static int a;

  int main() {
	  /* do something */
  }

is used as part of a larger program, I can just rename main
and get

  static int a;

  int do_something() {
	  ...
  }

But if the program

  static int a = 0;

  int main() {
	  /* do something */
  }

is used as part of a larger program, it has to become

  static int a;

  int do_something() {
	  a = 0;
	  ...
  }


You see that I, in my own code, follow a certain convention
where presence or absence of assignments means something
about the code. If now you change "static int a = 0;"
into "static int a;" and justify that by saying that it
generates the same code, then I am unhappy, because now
if I turn main() into do_something() I either get a buggy
program, or otherwise I have to read the source of main()
again to see which variables need initialisation.

In a program source there is information for the compiler
and information for the future me. Removing the " = 0"
is like removing comments. For the compiler the information
remains the same. For the programmer something is lost.

Andries
-
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/

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

[James A Sutherland]

On Sat, 25 Nov 2000, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
> 
> > No information is lost.
> 
> Do I explain things so badly? Let me try again.
> The difference between
> 
>   static int a;
> 
> and
> 
>   static int a = 0;
> 
> is the " = 0". The compiler may well generate the same code,

It does not. That's the whole point: the (functionally redundant) =0 wastes
another sizeof(int) bytes in the kernel image.

> but I am not talking about the compiler. I am talking about
> the programmer. This " = 0" means (to me, the programmer)
> that the correctness of my program depends on this initialization.

If you want to document your code like this, put it in a comment. That's what
they are there for. Or, if coding a function which explicitly relies on a
variable being 0, have that function set the variable to zero.

> Its absense means (to me) that it does not matter what initial
> value the variable has.

Which is silly. The variable is explicitly defined to be zero anyway, whether
you put this in your code or not.

> This is a useful distinction. It means that if the program
> 
>   static int a;
> 
>   int main() {
> 	  /* do something */
>   }
> 
> is used as part of a larger program, I can just rename main
> and get
> 
>   static int a;
> 
>   int do_something() {
> 	  ...
>   }
> 
> But if the program
> 
>   static int a = 0;
> 
>   int main() {
> 	  /* do something */
>   }
> 
> is used as part of a larger program, it has to become
> 
>   static int a;
> 
>   int do_something() {
> 	  a = 0;
> 	  ...
>   }

Just put:

static int a; /* must be set to zero in foobar() */

> You see that I, in my own code, follow a certain convention
> where presence or absence of assignments means something
> about the code.

Unfortunately, this handy documentation shortcut of yours bloats the kernel
unnecessarily.

> If now you change "static int a = 0;"
> into "static int a;" and justify that by saying that it
> generates the same code,

It does NOT generate the same code - that's the point. It generates smaller but
functionally equivalent code. The first version zeroes a TWICE, in effect; this
is completely unnecessary, and just bloats the kernel.

> then I am unhappy, because now
> if I turn main() into do_something() I either get a buggy
> program, or otherwise I have to read the source of main()
> again to see which variables need initialisation.

Oh no! You mean you might actually have to look at the code you're changing?!
This is hardly a valid reason for bloating the kernel! If you put the "this
variable must be zero when foo() is called" in a comment, rather than as a C
statement, it is equally clear to you - but avoids bloating the kernel.

> In a program source there is information for the compiler
> and information for the future me. Removing the " = 0"
> is like removing comments. For the compiler the information
> remains the same. For the programmer something is lost.

So put that comment in a real comment, rather than a redundant statement!


James.
-
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/

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

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:

> Which is silly. The variable is explicitly defined to be zero
> anyway, whether you put this in your code or not.

Why doesn't the compiler just leave out explicit zeros from the
'initial data' segment then?  Seems like it ought to be tought to..

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

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

[James A Sutherland]

On Sat, 25 Nov 2000, Tim Waugh wrote:
> 
> On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:
> 
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
> 
> Why doesn't the compiler just leave out explicit zeros from the
> 'initial data' segment then?  Seems like it ought to be tought to..

Good idea; unfortunately, it's probably too kernel-specific, so gcc may not
want to include this change. Also, the kernel is gcc version-specific; even if
this feature were automated in gcc now, it could take some time before the
kernel could safely be built under that version. Better to optimise the source
code to avoid the problem, rather than change the compiler to kludge around it.


James.
-
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/

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

[Tigran Aivazian]

On Sat, 25 Nov 2000, Tim Waugh wrote:

> On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:
> 
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
> 
> Why doesn't the compiler just leave out explicit zeros from the
> 'initial data' segment then?  Seems like it ought to be tought to..

yes, taught to, _BUT_ never let this to be a default option, please.
Because there are valid cases where a programmer things "this is in .data"
and that means this should be in .data. Think of binary patching an object
as one valid example (there may be others, I forgot).

Regards,
Tigran

-
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/

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

[Philipp Rumpf]

On Sun, Nov 26, 2000 at 10:37:07AM +0000, Tigran Aivazian wrote:
> On Sat, 25 Nov 2000, Tim Waugh wrote:
> > Why doesn't the compiler just leave out explicit zeros from the
> > 'initial data' segment then?  Seems like it ought to be tought to..
> 
> yes, taught to, _BUT_ never let this to be a default option, please.
> Because there are valid cases where a programmer things "this is in .data"

That's what __attribute__ ((section (".data"))) is for.

> and that means this should be in .data. Think of binary patching an object
> as one valid example (there may be others, I forgot).

can you think of any valid examples that apply to the kernel ?
-
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/

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

[Peter Samuelson]

[Tigran Aivazian]
> _BUT_ never let this to be a default option, please.  Because there
> are valid cases where a programmer things "this is in .data" and that
> means this should be in .data.

If you are writing the sort of code that cares which section it ends up
in, you need to use __attribute__((section)).  You probably will be
using things like __attribute__((align)) as well.  Relying on compiler
behavior here is dangerous.

I agree though that an option is called for, either -fassume-bss-zero
or -fno-assume-bss-zero, not sure which should be the default.

Peter
-
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/

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

[Michael Meissner]

On Sat, Nov 25, 2000 at 11:55:11PM +0000, Tim Waugh wrote:
> On Sat, Nov 25, 2000 at 10:53:00PM +0000, James A Sutherland wrote:
> 
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
> 
> Why doesn't the compiler just leave out explicit zeros from the
> 'initial data' segment then?  Seems like it ought to be tought to..

Because sometimes it matters.  For example, in kernel mode (and certainly for
embedded programs that I'm more familiar with), the kernel does go through and
zero out the so called BSS segment, so that normally uninitialized static
variables will follow the rules as laid out under the C standards (both C89 and
C99).  I can imagine however, that the code that is executed before the BSS
area is zeroed out needs to be extra careful in terms of statics that it
references, and those must be hand initialized.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
-
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/

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

[Jeff Garzik]

Andries Brouwer wrote:
> In a program source there is information for the compiler
> and information for the future me. Removing the " = 0"
> is like removing comments. For the compiler the information
> remains the same. For the programmer something is lost.

This is pretty much personal opinion :)

The C language is full of implicit as well as explicit features.  You
are arguing that using an implicit feature robs the programmer of
information.  For you maybe...  For others, no information is lost AND
the code is more clean AND the kernel is smaller.  It's just a matter of
knowing and internalizing "the rules" in your head.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso
-
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/

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

[Andries Brouwer]

On Sat, Nov 25, 2000 at 06:02:51PM -0500, Jeff Garzik wrote:
> Andries Brouwer wrote:
> > In a program source there is information for the compiler
> > and information for the future me. Removing the " = 0"
> > is like removing comments. For the compiler the information
> > remains the same. For the programmer something is lost.
> 
> This is pretty much personal opinion :)
> 
> The C language is full of implicit as well as explicit features.  You
> are arguing that using an implicit feature robs the programmer of
> information.  For you maybe...  For others, no information is lost AND
> the code is more clean AND the kernel is smaller.  It's just a matter of
> knowing and internalizing "the rules" in your head.

Oh Jeff,

All these really good people, unable to capture a simple idea.
Let me try one more time.
There is information. The information is:
	"this variable needs initialization"
Now you tell me to know simple rules. OK, I know them.
But what do they tell me about my variables a and b, where
a requires initialization and b does not require it?

One can write a comment, like

int a;	/* this variable needs initialization, fortunately
	   it is already initialized at startup */
int b;	/* no initialization required */

But that is overdoing it, it uglifies the code.
One can leave the comment out, like

int a, b;

But then next month, when you decide to move this into
some function

int foo() {
	int a, b;
...

there is no indication that you need an additional

	a = 0;

You see?
There is real information here. Useful as a reminder.
Not necessary. The perfect programmer would see
immediately that the assignment is required, also
without the reminder. But not everybody is perfect
all of the time, and sometimes the code involved is
quite complicated. The tiny convention
"write an explicit initialization when initialization is needed"
is helpful. It is a form of program documentation.

Andries
-
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/

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

[Martin Mares]

Hi Andries!

> All these really good people, unable to capture a simple idea.
> Let me try one more time.
> There is information. The information is:
> 	"this variable needs initialization"
> Now you tell me to know simple rules. OK, I know them.
> But what do they tell me about my variables a and b, where
> a requires initialization and b does not require it?

Distinguishing between variables initialized to zero and those not requiring
initialization is a good idea, but honestly, how common are static variables
declared at the top level which don't require initialization? 

				Have a nice fortnight
-- 
Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/
"RAM = Rarely Adequate Memory"
-
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/

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

[Herbert Xu]

On Sat, Nov 25, 2000 at 11:46:24PM +0100, Andries Brouwer wrote:
> 
> But if the program
> 
>   static int a = 0;
> 
>   int main() {
> 	  /* do something */
>   }
> 
> is used as part of a larger program, it has to become
> 
>   static int a;
> 
>   int do_something() {
> 	  a = 0;
> 	  ...
>   }

Only if the person doing the change follows this convention, if that happens
to be you, not a problem.  But in a project like Linux, it's not very likely
to happen.

It's much better to put a comment above the definition.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/

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

[Helge Hafting]

Andries Brouwer wrote:
> 
> On Sun, Nov 26, 2000 at 09:11:18AM +1100, Herbert Xu wrote:
> 
> > No information is lost.
> 
> Do I explain things so badly? Let me try again.
> The difference between
> 
>   static int a;
> 
> and
> 
>   static int a = 0;
> 
> is the " = 0". The compiler may well generate the same code,
> but I am not talking about the compiler. I am talking about
> the programmer. This " = 0" means (to me, the programmer)
> that the correctness of my program depends on this initialization.
> Its absense means (to me) that it does not matter what initial
> value the variable has.

Seems to me few other people think that way, thats why it is so
har for them to get.  And thats why this style of coding isn't very
helpful either.  It may be a real help for you, but not for others
who merely get confused or irritated at the small but easy to eliminate
micro-bloat.

There are certainly people so used to the implicit zeroing that they
think of "static int a;" as a zero initialization as explicit as
anything, because that's the way the language works. And they will
take just as much care if the "a-using" code is modified to run twice.
The "=0" part don't make it clearer for them if it was clear already.

Helge Hafting
-
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/

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

[Albert D. Cahalan]

Andries Brouwer writes:

> Do I explain things so badly? Let me try again.
> The difference between
> 
>   static int a;
> 
> and
> 
>   static int a = 0;
> 
> is the " = 0". The compiler may well generate the same code,
> but I am not talking about the compiler. I am talking about
> the programmer. This " = 0" means (to me, the programmer)
> that the correctness of my program depends on this initialization.
> Its absense means (to me) that it does not matter what initial
> value the variable has.

It is too late to fix things now. It would have been good to
have the compiler put explicitly zeroed data in a segment that
isn't shared with non-zero or uninitialized data, so that the
uninitialized data could be set to 0xfff00fff to catch bugs.
It would take much effort over many years to make that work.

I'd rather see the compiler optimize for cache line use and
make use of small address offsets to load variables.
-
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/

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

[Russell King]

Albert D. Cahalan writes:
> It is too late to fix things now. It would have been good to
> have the compiler put explicitly zeroed data in a segment that
> isn't shared with non-zero or uninitialized data, so that the
> uninitialized data could be set to 0xfff00fff to catch bugs.
> It would take much effort over many years to make that work.

Oh dear, here's that misconception again.

static int a;

isn't a bug.  It is not "uninitialised data".  It is defined to be
zero.  Setting the BSS of any C program to contain non-zero data will
break it.  Fact.  The only bug you'll find is the fact that you're
breaking the C standard.

There is only two places where you come across uninitialised data:

1. memory obtained from outside text, data, bss limit of the program
   (ie, malloced memory)
2. if you use auto variables which may be allocated on the stack

All variables declared at top-level are initialised.  No questions
asked.  And its not a bug to rely on such a fact.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
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/

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

[Albert D. Cahalan]

Russell King writes:
> Albert D. Cahalan writes:

>> It is too late to fix things now. It would have been good to
>> have the compiler put explicitly zeroed data in a segment that
>> isn't shared with non-zero or uninitialized data, so that the
>> uninitialized data could be set to 0xfff00fff to catch bugs.
>> It would take much effort over many years to make that work.
>
> Oh dear, here's that misconception again.
>
> static int a;
>
> isn't a bug.

Alone, it is not.

> It is not "uninitialised data".  It is defined to be
> zero.  Setting the BSS of any C program to contain non-zero data will
> break it.  Fact.  The only bug you'll find is the fact that you're
> breaking the C standard.

Oh, bullshit. We break the C standard left and right already.
This is the kernel, and the kernel can initialize BSS any damn
way it feels like initializing it. The kernel isn't ever going
to be standard C.

Choosing an initializer that tends to catch unintended reliance
on zeroed data would be good. Too bad it is too late to fix.

> All variables declared at top-level are initialised.  No questions
> asked.  And its not a bug to rely on such a fact.

Go back and read the rest of this thread. Examples have been
provided (not by me) of such code leading to latter mistakes.
-
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/

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

[Peter Samuelson]

[Albert D. Cahalan]
> Choosing an initializer that tends to catch unintended reliance on
> zeroed data would be good. Too bad it is too late to fix.

Why would that be good?  Why is it bad to accidentally rely on zeroed
data, if the data is in fact guaranteed to be zeroed?  It's not like
this is going to change out from under us in a year.  You said it
yourself: we can do whatever we want here.  And I don't see why we
would ever want to do anything other than zero it.

> Go back and read the rest of this thread. Examples have been provided
> (not by me) of such code leading to latter mistakes.

Oh please, how hard can it be to type

  static int foo; // = 0

as opposed to

  static int foo = 0;

If the two produced the same object code, the second would be better,
but they don't, so it isn't.  Patch gcc, if you care enough (and feel
you can convince the gcc steering committee to care enough).

Peter
-
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/

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

[Russell King]

Albert D. Cahalan writes:
> Oh, bullshit. We break the C standard left and right already.
> This is the kernel, and the kernel can initialize BSS any damn
> way it feels like initializing it. The kernel isn't ever going
> to be standard C.
> 
> Choosing an initializer that tends to catch unintended reliance
> on zeroed data would be good. Too bad it is too late to fix.

Its not me talking bullshit here, its you.  It is totally reasonable
to rely on:

  static int foo;

to be zero.  If it is not, that is a bug in the C startup code.  No
two ways about it.  If someone then says "I want to initialise the
BSS to some magic value to catch this reliance" then we are breaking
a lot of peoples expectations.  (Least Surprise theory)

To say again, relying on foo to be zero is not a bug.

If you set the BSS to something non-zero, we already know that a lot
will break.  But it will break because someone has broken the BSS
initialisation code, not because it is relying on something that is
expected to be standard.  By setting the BSS to something non-zero,
you're not telling anyone anything new.  About the only response
will be "fix the BSS initialisation".

If you want to try this, then that is up to you.  Don't let us
stop you.  However, don't expect people to accept patches to
"fix" your self-created problem.

I look forward to your complaints about the disk subsystems,
keyboard, console, and so forth apparantly being broken.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
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/

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

[Tigran Aivazian]

Hello Andries,

On Sat, 25 Nov 2000, Andries Brouwer wrote:
> What a strange reaction. If I write
> 
>  static int foo;
> 
> this means that foo is a variable, local to the present compilation unit,
> whose initial value is irrelevant because it will be assigned to before use.
> If I write
> 
>  static int foo = 0;
> 
> this means that the code depends on the initialization.
> Indeed, it is customary to write
> 
>  int foo = 0;  /* just for gcc */
> 
> when the initialization in fact is not necessary.

What I am suggesting (in fact, not me but common sense) is that if you
write:

static int foo;

then you really mean "a variable is foo and since it is required to be
initialized to zero, I am quite free to _rely_ on this fact and will
possibly do so". It is true that information about whether you actually
rely on it or not is lost but surely such "loss" is worth being able to
run Linux rather than non-Linux (i.e. in the cases where it is a matter of
a "few bytes" that decides whether you _can_ run Linux or not at all, i.e.
presumably some small devices where you have to squeeze Linux with a given
set of drivers into finite room).

> Saving a byte in the binary image is not very interesting. Preserving
> information about the program is important.

Saving a single byte may not be. Some studies have shown that the total is
in the range of a megabyte, that is first. The second is -- developing the
optimal set of mind (namely that described above around "static int foo;"
) is very interesting as it ensures that Linux remains optimal even as it
and the number of people working on it grows astronomically. You must have
seen the source code of various commercial flavours of UNIX and therefore
understand why they are such a failure -- there is no one like Linus
Torvalds behind them which has so much patience that he gratefully accepts
all improvements, however small they may seem. I hope that Linux will
remain the cleanest system wrt attention to detail. Yes, I understand that
it requires absolutely _impossible_ amount of patience on the part of
Linus Torvalds, but that is indeed what he does -- the impossible and may
God bless him and keep him.

> 
> I see that this message is cc'ed to Tigran, so let me address him as well.
> Tigran, you like to destabilize Linux. I like to stabilize Linux.
> 

Oh, Andries, that is insulting. Surely you do not really mean that. So, I
_will_ read the rest of your message. :)

> If it is your intention to destabilize then you need not read the following.
> But let us assume that you try to make a perfect system.
> 
> There is the issue of local and global correctness.
> A piece of code is locally correct when its correctness can be seen
> by just looking at those lines, or that function, or that source file.
> A piece of code is globally correct when you need to read the entire kernel
> source to convince yourself that all is well.
> 
> Often local correctness is obtained by local tests. After reading the entire
> kernel source you conclude that these tests are superfluous because they
> are satisfied in all cases. And you think it is an improvement to remove
> the test. It almost never is. On a fast path, where every cycle counts, yes.
> But it is not a good idea to sacrifice local correctness and save five
> kernel image bytes, or speed up the mount system call by 0.001%.
> Why not? Because you read the entire kernel source of today.
> But not that of next week. Somewhere someone changes some code.
> The test is gone and the kernel crashes instead of returning an error.

your theory is very good, in theory, but is not so in practice. Namely, if
you cared to look in depth at the specific instances of the optimizations
I suggested which required what you call "global correctness checks" (I
like that terminology!) then you would either have found out that either:

a) I have done enough investigations to show that such tests can not only
be removed now but nothing in the future should ever require them to be
added.

or

b) I have made a mistake, in which case, I would be happy to see you
correcting me. Failure to do so indicates that I was right.

in both cases, I did not intentionally sacrifice "local correctness" as
you are trying to present. I think I value local correctness as much as
you do.

> You even like to destabilize when there is no gain in size or speed at all.
> It is bad coding practice to use casts. They tell the compiler not to check.
> With functions returning (void *) the opposite is true. The compiler cannot
> check now, but given a cast, it can. Thus, I wrote a few months ago
> 
> > If one just writes
> >       foo = kmalloc(n * sizeof(some_type), GFP_x);
> > then neither the compiler nor the human eye can check
> > easily that things are right, i.e. that foo really is
> > a (some_type *). Therefore it is better to write
> >       foo = (some_type *) kmalloc(n * sizeof(some_type), GFP_x);
> 
> To my surprise you answered
> 
> : It is a small thing, Andries, but I still think otherwise than you.
> : It is better for code to be smaller than to be slightly more fool-proof.

Again, in theory you sound quite right. In practice, the specific cases
where I proposed removing such typecasts were immediately preceeded by the
declarations of the corresponding variables. I.e. it was _immediately_
obvious as to what type they are and those long casts were only making
code bigger, nothing else. You will certainly find quite a large number of
places where those casts are still there -- this is not because I haven't
seen them but because I didn't think worth changing (probably for the very
reason you kindly explained to me, for this I thank you!)

> 
> Please change your mind.
> 
> Andries

I have changed my mind about one thing -- there is a common sense or
"sense of measure" about what should and what should not be cc'd to
linux-kernel and I certainly was neglecting such "sense of measure" if I
allowed a mail like yours to come into existence. Nevertheless, it is
gratefully noted and will be acted upon accordingly.

Regards,
Tigran

-
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/

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

[Andries Brouwer]

On Sat, Nov 25, 2000 at 10:27:15PM +0000, Tigran Aivazian wrote:
: Hello Andries,

Hi Tigran,

: ... I am quite free to _rely_ on this fact and will possibly do so.

Yes, you are. But some programmers have learned that it is a good
idea to code in a way that is informative to the programmer.

: > Tigran, you like to destabilize Linux.
: 
: Oh, Andries, that is insulting. Surely you do not really mean that.

No insult intended.
It is just that if there is an abyss somewhere, I like to stay at least
a meter away from it. Someone else may think that one inch suffices.
I see you propose a lot of changes that yield a negligable advantage
and reduce stability a tiny little bit. That is pushing Linux in the
direction of this abyss. You notice that the view gets better, and I
get nervous.

You seem to have these strange ideas. I quoted you

: It is better for code to be smaller than to be slightly more fool-proof.

Here is a different one:

: I think that the check for inode->i_op == NULL in various vfs_XXX()
: functions is bogus, i.e. if it is NULL then it must be a bug in
: some filesystem's ->read_inode() method and therefore, instead of
: returning error to userspace we should immediately panic, since
: it is a kernel bug.

Does the kernel contain a bug? Panic!  I don't think my alpha would
have gotten an uptime of 1198 days under that paradigm.
(I don't think you were serious, but still..)

  [I am not so sure why i_op == NULL necessarily is a bug.
  Sometimes a routine invents a dummy inode just because it is needed
  in some calling convention, while nothing of this inode is used
  except for example i_rdev. Maybe it does not occur today, in the
  filesystems in the 2.4 kernel tree. But such checks: test i_op,
  then test i_op->function, then call i_op->function() ensure
  a local correctness. That is what I like.
  Reading all filesystems in the kernel tree is what I don't like.
  And there are many filesystems not in the kernel tree.]

This is not to debate this particular case - it is Al's business.
This is just an example where you want to sacrifice local correctness
and be satisfied with global correctness.

: "sense of measure"

Yes, well formulated!

But this was a communication to linux-kernel, not an attack.
It was meant to say two things, namely
(i) Source code is a communication to programmers and to the compiler.
It is a bad idea to optimize the communication towards the compiler
when that is detrimental to the communication towards programmers.
And (ii) locally correct code is more stable than code that is only
globally correct.

For me these are truisms, but when Rusty complained about loss of
information lots of people did not seem to understand what could be meant.
I took you as my victim because you always seem to take the point
of view that the code must be perfect, never mind the programmers,
and that it is a good idea to save a few instructions, never mind
local correctness. (And also because your old remark quoted above
still required a reaction.)

No offense intended.

Andries
-
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/

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

[Werner Almesberger]

Andries Brouwer wrote:
> On Sat, Nov 25, 2000 at 10:27:15PM +0000, Tigran Aivazian wrote:

I think it's a bad sign if people like the two of you start flaming
each other ...

On the issue of  static int foo = 0;  vs.  static int foo;  I'd agree
with Andries' view. It's a common enough idiom that it is useful to
convey the intentions of the programmer.

On "optimizing" changes: there are plenty of very ugly things you can
do to a C program to make source or object code smaller (e.g. use only
one-character identifiers for smaller code; re-use variables as much
as possible, maybe with casts for smaller stack footprint, etc.). We
usually avoid these too, so a few extra initializations in the source
shouldn't hurt.

On the .data segment size: if all the energy that went into this
thread would have gone into implementing a gcc option to move all-zero
.data objects to .bss, the technical side of the problem would be
solved already ;-)

> Does the kernel contain a bug? Panic!  I don't think my alpha would
> have gotten an uptime of 1198 days under that paradigm.
> (I don't think you were serious, but still..)

Hmm, sometimes a panic _is_ the right answer, though. If a critical
subsystem just politely returns an error to user space and tries to
continue, it may take a while until somebody realizes that there's
something wrong at all ...

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
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/

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

[Georg Nikodym]

>>>>> "AB" == Andries Brouwer <aeb@veritas.com> writes:

 AB> No insult intended.  It is just that if there is an abyss
 AB> somewhere, I like to stay at least a meter away from it. Someone
 AB> else may think that one inch suffices.  I see you propose a lot
 AB> of changes that yield a negligable advantage and reduce stability
 AB> a tiny little bit. That is pushing Linux in the direction of this
 AB> abyss. You notice that the view gets better, and I get nervous.

Can somebody stop this train load of bunk?

Uninitialized global variables always have a initial value of
zero.  Static or otherwise.  Period.

Anybody with more than a week's experience programming knows this.
It's idiomatic.  Just as in English one says, "Go away!" knowing that
"You", the implied subject of the imperative sentence, will be
understood.

Andries, please devote your impressive energy to fixing _real_ bugs.
This kind of argument is best left until we're _really_ low on other
things to do.
-
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/

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

[Alan Cox]

>  AB> of changes that yield a negligable advantage and reduce stability
>  AB> a tiny little bit. That is pushing Linux in the direction of this
>  AB> abyss. You notice that the view gets better, and I get nervous.
> 
> Can somebody stop this train load of bunk?
> 
> Uninitialized global variables always have a initial value of
> zero.  Static or otherwise.  Period.

That isnt what Andries is arguing about. Read harder. Its semantic differences
rather than code differences.

	static int a=0;

says 'I thought about this. I want it to start at zero. I've written it this
way to remind of the fact'

Sure it generates the same code

-
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/

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

[John Alvord]

On Sun, 26 Nov 2000 04:25:05 +0000 (GMT), Alan Cox
<alan@lxorguk.ukuu.org.uk> wrote:

>>  AB> of changes that yield a negligable advantage and reduce stability
>>  AB> a tiny little bit. That is pushing Linux in the direction of this
>>  AB> abyss. You notice that the view gets better, and I get nervous.
>> 
>> Can somebody stop this train load of bunk?
>> 
>> Uninitialized global variables always have a initial value of
>> zero.  Static or otherwise.  Period.
>
>That isnt what Andries is arguing about. Read harder. Its semantic differences
>rather than code differences.
>
>	static int a=0;
>
>says 'I thought about this. I want it to start at zero. I've written it this
>way to remind of the fact'
>
>Sure it generates the same code

It also says "I do not know much about the details of the kernel C
environment. In particular I do not know that all static variables are
initialized to 0 in the kernel startup. I have not read setup.S."

john alvord
-
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/

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

[Andre Hedrick]

On Sun, 26 Nov 2000, John Alvord wrote:

> On Sun, 26 Nov 2000 04:25:05 +0000 (GMT), Alan Cox
> <alan@lxorguk.ukuu.org.uk> wrote:
> 
> >>  AB> of changes that yield a negligable advantage and reduce stability
> >>  AB> a tiny little bit. That is pushing Linux in the direction of this
> >>  AB> abyss. You notice that the view gets better, and I get nervous.
> >> 
> >> Can somebody stop this train load of bunk?
> >> 
> >> Uninitialized global variables always have a initial value of
> >> zero.  Static or otherwise.  Period.
> >
> >That isnt what Andries is arguing about. Read harder. Its semantic differences
> >rather than code differences.
> >
> >	static int a=0;
> >
> >says 'I thought about this. I want it to start at zero. I've written it this
> >way to remind of the fact'
> >
> >Sure it generates the same code
> 
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."

Are you positive for modules too...

Regardless of the fact you have displayed, some of us prefer to clobber it
to insure that it stays zero until access.  Last thing you want is an
unstatic static when we go to spin a disk for data.

Just how warm and fuzzy do you fell if your block drivers do not insure
this point?

Cheers,

Andre Hedrick
Linux ATA Development

-
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/

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

[Keith Owens]

On Sat, 25 Nov 2000 21:10:19 -0800 (PST), 
Andre Hedrick <andre@linux-ide.org> wrote:
>On Sun, 26 Nov 2000, John Alvord wrote:
>> It also says "I do not know much about the details of the kernel C
>> environment. In particular I do not know that all static variables are
>> initialized to 0 in the kernel startup. I have not read setup.S."
>
>Are you positive for modules too...

Yes.

-
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/

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

[Andre Hedrick]

On Sun, 26 Nov 2000, Keith Owens wrote:

> >Are you positive for modules too...
> 
> Yes.

I know this, I am being punchy.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
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/

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

[Tigran Aivazian]

On Sun, 26 Nov 2000, John Alvord wrote:
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."

John, please stop insulting Andries, you would be _surprized_ to find out
how much he actually knows about a multitude of things.

As for Andries' point of loss of information, he has a point, _but_ James'
suggestion to put that extra info in the comment, imho, outweighs the
small disadvantages (code looks a bit uglier) which Andries pointed out to
counter it.

Regards,
Tigran.

-
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/

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

[Tigran Aivazian]

On Sun, 26 Nov 2000, John Alvord wrote:
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."
                                                          ~~~~~~~~~

Sorry, John, I _have_ to [give good example to others]. The above says
that _you_ my dear friend, do not know where the BSS clearing code is. It
is not in setup.S. It is not even in the same directory, where setup.S is.
It is in arch/i386/kernel/head.S, starting from line 120:

/*
 * Clear BSS first so that there are no surprises...
 */
        xorl %eax,%eax
        movl $ SYMBOL_NAME(__bss_start),%edi
        movl $ SYMBOL_NAME(_end),%ecx
        subl %edi,%ecx
        cld
        rep
        stosb

... speaking of which (putting asbesto on and hiding from Andries ;) can't
we optimize this code to move words at a time and not bytes.... ;)

Regards,
Tigran

-
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/

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

[Pavel Machek]

Hi!

> Sorry, John, I _have_ to [give good example to others]. The above says
> that _you_ my dear friend, do not know where the BSS clearing code is. It
> is not in setup.S. It is not even in the same directory, where setup.S is.
> It is in arch/i386/kernel/head.S, starting from line 120:
> 
> /*
>  * Clear BSS first so that there are no surprises...
>  */
>         xorl %eax,%eax
>         movl $ SYMBOL_NAME(__bss_start),%edi
>         movl $ SYMBOL_NAME(_end),%ecx
>         subl %edi,%ecx
>         cld
>         rep
>         stosb
> 
> ... speaking of which (putting asbesto on and hiding from Andries ;) can't
> we optimize this code to move words at a time and not bytes.... ;)

There's better way: put bss clearing code at beggining of .C code and
do it with memset. [x86-64 does it this way.] It is both more obvious
[no assembly] and faster [memset is optimized].
								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
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/

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

[bert hubert]

On Sun, Nov 26, 2000 at 10:52:05AM +0000, Tigran Aivazian wrote:

> that _you_ my dear friend, do not know where the BSS clearing code is. It
> is not in setup.S. It is not even in the same directory, where setup.S is.
> It is in arch/i386/kernel/head.S, starting from line 120:

On a related note, I seem to remember that back in the dark ages, the BSS
wasn't cleared. It said so somewhere in the Kernel Hackers Guide, I think.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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/

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

[Rogier Wolff]

John Alvord wrote:
> On Sun, 26 Nov 2000 04:25:05 +0000 (GMT), Alan Cox
> <alan@lxorguk.ukuu.org.uk> wrote:
> 
> >>  AB> of changes that yield a negligable advantage and reduce stability
> >>  AB> a tiny little bit. That is pushing Linux in the direction of this
> >>  AB> abyss. You notice that the view gets better, and I get nervous.
> >> 
> >> Can somebody stop this train load of bunk?
> >> 
> >> Uninitialized global variables always have a initial value of
> >> zero.  Static or otherwise.  Period.
> >
> >That isnt what Andries is arguing about. Read harder. Its semantic differences
> >rather than code differences.
> >
> >	static int a=0;
> >
> >says 'I thought about this. I want it to start at zero. I've written it this
> >way to remind of the fact'
> >
> >Sure it generates the same code
> 
> It also says "I do not know much about the details of the kernel C
> environment. In particular I do not know that all static variables are
> initialized to 0 in the kernel startup. I have not read setup.S."

Nope. It doesn't say that. Maybe if you wrote the code. But if Andries
or I had written that line, it just says that when written the
programmer thought about the initial value, and that the initial value
matters on this variable. 

It is a concise form of documentation. As Andries explained, this can
also be done with comments or with 

	static int a /* = 0 */; 

However, I like the "=0" variant much better. 

If you're worried about the inefficiency of the compiler, take it up
with the compiler guys. Or write an extra preprocessor step or
something like that.

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

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

[Philipp Rumpf]

On Sun, Nov 26, 2000 at 04:25:05AM +0000, Alan Cox wrote:
> 	static int a=0;
> 
> says 'I thought about this. I want it to start at zero. I've written it this
> way to remind of the fact'
> 
> Sure it generates the same code

I agree it would be best if gcc would generate the same code;  unfortunately
this doesn't seem to be the case, which sounds like something to take up with
the gcc developers.
-
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/

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

[H. Peter Anvin]

Followup to:  <E13ztNR-0001ew-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
> 
> That isnt what Andries is arguing about. Read harder. Its semantic differences
> rather than code differences.
> 
> 	static int a=0;
> 
> says 'I thought about this. I want it to start at zero. I've written it this
> way to remind of the fact'
> 
> Sure it generates the same code
> 

The problem is that it doesn't.  One could argue this is a gcc bug or
rather missed optimization.

One can, of course, also write:

    static int a /* = 0 */;

... to make it clear to human programmers without making gcc make bad
code.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

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

[Kai Henningsen]

hpa@zytor.com (H. Peter Anvin)  wrote on 26.11.00 in <8vrstp$o7d$1@cesium.transmeta.com>:

> The problem is that it doesn't.  One could argue this is a gcc bug or
> rather missed optimization.
>
> One can, of course, also write:
>
>     static int a /* = 0 */;
>
> ... to make it clear to human programmers without making gcc make bad
> code.

This (or similar) has the added advantage of making it obvious that this  
is documentation, and not a superfluous initialization.

Sure, if you (generic you) look at your own code, you may know what it  
means if it's written a certain way. But if you look at other's code, or  
others look at your code, that is not clear. It is clear with a comment.


MfG Kai
-
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/

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

[Georg Nikodym]

>>>>> "AC" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

 AC> Sure it generates the same code

If you accept that code == .text, as do I, then there is no code
generated for either of the forms being argued.
-
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/