Darryl Miles writes:
> Hmm, what about common symbol generation? i.e. the linker looses the
> ability to throw out "multiply defined symbol" errors where you fail
> to initialise it to a value.
We need to build with -fno-common to be 100% safe in this case. I'll
run several compilations with th
Russell King <[EMAIL PROTECTED]> writes:
>The only difference is the size on disk; if we go around setting every
>bss variable to zero, the kernel/module data size will unnecessarily
>huge.
Hmm, what about common symbol generation? i.e. the linker looses the
ability
to throw out "multiply defin
On Wed, 29 Nov 2000, Peter Samuelson wrote:
> It would probably also be reasonable to document it and provide an
> option to switch it off.
yes, that is perfectly fine by me. Now, who is going to do the _work_? :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux
[Tigran Aivazian <[EMAIL PROTECTED]>]
> no, I was not talking about ISO C standards but about the normal
> expected C environment under any UNIX. I guess, we just mean
> different things by "trivially equivalent" since neither of us said
> anything about what that actually meant. What I meant by
On Tue, 28 Nov 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > First, they are not trivially equivalent. In fact, they are not
> > equivalent at all. Any good C book should tell you that one places
> > data in "data segment" and another in "bss segment" (with a footnote
> > explaining histor
[Keith Owens]
> Binary patches against bss on disk cannot work, there is nothing to
> patch.
OK, me dumkopf.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 28 Nov 2000 17:53:48 -0600,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>Binary patching? If you are binary patching something you need to get
>the exact location, one way or another. Whatever tool you use to
>extract the location of a symbol in an object file, that same tool
>should tel
[Tigran Aivazian]
> First, they are not trivially equivalent. In fact, they are not
> equivalent at all. Any good C book should tell you that one places
> data in "data segment" and another in "bss segment" (with a footnote
> explaining historical meaning of "block started by symbol")
Do you ha
On Tue, 28 Nov 2000, David Hinds wrote:
> I would contend that it is a compiler bug in gcc if it treats the two
> statements differently, since they are trivially equivalent. I guess
> that it has been decided that linux kernel coding style dictates no
> zero initializers, so that's that. Person
> 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;
I think the argument is that "static int foo;" implies you don't
actually care how "foo"
On Tue, Nov 28, 2000 at 02:19:23PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> > > What irritates about these monkey-see-monkey-do patches is that if I
> > > initialize a variable to NULL, it's because
On Thu, 23 Nov 2000, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > Quick removal of unnecessary initialization to 0.
> >
> > Quite the contrary. The patch seems correct and useful to me. What
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
J . A . Magallon writes:
> ANSI rules for C say that uninitialized vars get a 0, but you can't trust
> on the ANSI behaviour of a compiler.
It has nothing to do with the compiler, but everything to do with the
C startup code. In the Linux kernel, we have complete control over the
C startup code
On Thu, 23 Nov 2000 12:01:53 Rusty Russell wrote:
>
> 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 I understood from the previous answer from
On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > Quick removal of unnecessary initialization to 0.
> >
> > Quite the contrary. The patch seems correct and
In message <[EMAIL PROTECTED]> you write:
> > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Quick removal of unnecessary initialization to 0.
>
> Quite the contrary. The patch seems correct and useful to me. What do you
> think is wrong with it? (Linus accepted megaby
J . A . Magallon writes:
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > -static int basePort = 0; /* base port address */
> > -static int regPort = 0;/* port for register number */
> > -static int dataPort = 0; /* port for register data */
> > +static int baseP
"J . A . Magallon" wrote:
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> > -static int dataPort = 0; /* port for register data */
> > +static int dataPort; /* port for register data */
>
> That is not too much confidence on the ANSI-ness of the compiler ???
There is nothin
On Wed, 22 Nov 2000 00:26:23 Tigran Aivazian wrote:
> On Wed, 22 Nov 2000, J . A . Magallon wrote:
>
> In the case of kernel, we have to do many things manually, can't rely on
> some compiler (sometimes :). So, the code I pointed you at
> arch/i386/kernel/head.S (look for "Clear BSS") is in fact
On Wed, 22 Nov 2000, J . A . Magallon wrote:
>
> On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote:
> > On Tue, 21 Nov 2000, J . A . Magallon wrote:
> >
> > Quite the contrary. The patch seems correct and useful to me. What do you
> > think is wrong with it? (Linus accepted megabytes worth of
On Wed, 22 Nov 2000 00:04:53 Tigran Aivazian wrote:
> On Tue, 21 Nov 2000, J . A . Magallon wrote:
>
> Quite the contrary. The patch seems correct and useful to me. What do you
> think is wrong with it? (Linus accepted megabytes worth of the above in
> the past...)
>
Sorry, i should look at th
On Tue, 21 Nov 2000, J . A . Magallon wrote:
>
> On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
> >
> > Quick removal of unnecessary initialization to 0.
> >
> >
> > -static int basePort = 0; /* base port address */
> > -static int regPort = 0;/* port for registe
On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote:
>
> Quick removal of unnecessary initialization to 0.
>
>
> -static int basePort = 0; /* base port address */
> -static int regPort = 0; /* port for register number */
> -static int dataPort = 0; /* port for re
Hi
Quick removal of unnecessary initialization to 0.
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>
diff -uNr linux-240t11/drivers/ide/ali14xx.c linux/drivers/ide/ali14xx.c
--- linux-240t11/drivers/ide/ali14xx.c Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ali14xx.c Tue Nov 21 14:35:59 2
25 matches
Mail list logo
