[KJ] setting fops member pointers to NULL?

[KJ] setting fops member pointers to NULL?

[Robert P. J. Day]

  is there any rationale for setting a member of the file_operations
structure explicitly to NULL as opposed to leaving it initialized?  i
would think that's the default just based on the rules for C
initialization, but i just wanted to make sure since i see it done
every so often and wonder if there's something tricky going on that i
don't know about.

rday

-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Aaron Cripps]

Robert P. J. Day wrote:
>   is there any rationale for setting a member of the file_operations
> structure explicitly to NULL as opposed to leaving it initialized?  i
> would think that's the default just based on the rules for C
> initialization, but i just wanted to make sure since i see it done
> every so often and wonder if there's something tricky going on that i
> don't know about.
>
> rday
>
>   
Actually, C doesn't really care ... if you declare something, but don't 
initialize it explicitly,
it will be filled with some random value (probably whatever was at the 
given memory address
before C gave it to your var). It makes sense to initialize something to 
NULL because then
we can run value checks and we know what to expect if the value isn't  
something we put in there.
Hope this helps.
-acripps
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[John Anthony Kazos Jr.]

> >   is there any rationale for setting a member of the file_operations
> > structure explicitly to NULL as opposed to leaving it initialized?  i
> > would think that's the default just based on the rules for C
> > initialization, but i just wanted to make sure since i see it done
> > every so often and wonder if there's something tricky going on that i
> > don't know about.
> > 
> > rday
> > 
> >   
> Actually, C doesn't really care ... if you declare something, but don't
> initialize it explicitly,
> it will be filled with some random value (probably whatever was at the given
> memory address
> before C gave it to your var). It makes sense to initialize something to NULL
> because then
> we can run value checks and we know what to expect if the value isn't
> something we put in there.

No, it depends on the linkage. Check the C standard. If something has 
static storage duration it is initialized to zero, and gcc will put it in 
the bss section (but will take it back out if you explicitly initialize it 
to zero, for some stupid reason). Variables with automatic storage 
duration (on the stack) are not initialized and must be explicitly made 
so.

static struct file_system_type e2fs_file_system_type {
	/* foo */
};

You would initialize only the members that actually do something. If it 
weren't "static", then you would need to.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Arnaldo Carvalho de Melo]

On 5/29/07, Aaron Cripps <acripps@gmail.com> wrote:
> Robert P. J. Day wrote:
> >   is there any rationale for setting a member of the file_operations
> > structure explicitly to NULL as opposed to leaving it initialized?  i
> > would think that's the default just based on the rules for C
> > initialization, but i just wanted to make sure since i see it done
> > every so often and wonder if there's something tricky going on that i
> > don't know about.
> >
> > rday
> >
> >
> Actually, C doesn't really care ... if you declare something, but don't
> initialize it explicitly,
> it will be filled with some random value (probably whatever was at the
> given memory address
> before C gave it to your var).

Nope. If it is a global variable and it is left uninitialized it will
be put into the .bss section and thus set to zero at program start.

If you use named initializers in struct initializations, no matter
where, the uninitialized members will be set to zero too.


- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Robert P. J. Day]

On Tue, 29 May 2007, Arnaldo Carvalho de Melo wrote:

> On 5/29/07, Aaron Cripps <acripps@gmail.com> wrote:
> > Robert P. J. Day wrote:
> > >   is there any rationale for setting a member of the file_operations
> > > structure explicitly to NULL as opposed to leaving it initialized?  i
> > > would think that's the default just based on the rules for C
> > > initialization, but i just wanted to make sure since i see it done
> > > every so often and wonder if there's something tricky going on that i
> > > don't know about.
> > >
> > > rday
> > >
> > >
> > Actually, C doesn't really care ... if you declare something, but don't
> > initialize it explicitly,
> > it will be filled with some random value (probably whatever was at the
> > given memory address
> > before C gave it to your var).
>
> Nope. If it is a global variable and it is left uninitialized it
> will be put into the .bss section and thus set to zero at program
> start.
>
> If you use named initializers in struct initializations, no matter
> where, the uninitialized members will be set to zero too.

that's the understanding i had, so setting those global member fields
to NULL in various fops structures is really redundant.  doesn't hurt
anything, of course.

rday
-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[John Anthony Kazos Jr.]

> > > >   is there any rationale for setting a member of the file_operations
> > > > structure explicitly to NULL as opposed to leaving it initialized?  i
> > > > would think that's the default just based on the rules for C
> > > > initialization, but i just wanted to make sure since i see it done
> > > > every so often and wonder if there's something tricky going on that i
> > > > don't know about.
> > > >
> > > > rday
> > > >
> > > >
> > > Actually, C doesn't really care ... if you declare something, but don't
> > > initialize it explicitly,
> > > it will be filled with some random value (probably whatever was at the
> > > given memory address
> > > before C gave it to your var).
> >
> > Nope. If it is a global variable and it is left uninitialized it
> > will be put into the .bss section and thus set to zero at program
> > start.
> >
> > If you use named initializers in struct initializations, no matter
> > where, the uninitialized members will be set to zero too.
> 
> that's the understanding i had, so setting those global member fields
> to NULL in various fops structures is really redundant.  doesn't hurt
> anything, of course.

Well, it does increase the on-disk image size. Like when code uses 
THIS_MODULE but is compiled built-in. But there're not many people who are 
going to really be interested in adding an ifdef to save that few bytes, 
unfortunately.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Bernd Petrovitsch]

On Tue, 2007-05-29 at 10:55 -0400, John Anthony Kazos Jr. wrote:
> > > > >   is there any rationale for setting a member of the file_operations
> > > > > structure explicitly to NULL as opposed to leaving it initialized?  i
> > > > > would think that's the default just based on the rules for C
> > > > > initialization, but i just wanted to make sure since i see it done
> > > > > every so often and wonder if there's something tricky going on that i
> > > > > don't know about.
> > > > >
> > > > > rday
> > > > >
> > > > >
> > > > Actually, C doesn't really care ... if you declare something, but don't
> > > > initialize it explicitly,
> > > > it will be filled with some random value (probably whatever was at the
> > > > given memory address
> > > > before C gave it to your var).
> > >
> > > Nope. If it is a global variable and it is left uninitialized it
> > > will be put into the .bss section and thus set to zero at program
> > > start.
> > >
> > > If you use named initializers in struct initializations, no matter
> > > where, the uninitialized members will be set to zero too.
> > 
> > that's the understanding i had, so setting those global member fields
> > to NULL in various fops structures is really redundant.  doesn't hurt
> > anything, of course.
> 
> Well, it does increase the on-disk image size. Like when code uses 

The original question was about unused fields in (e.g.) struct
file_operations.
Are you sure your comment makes any sense then?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Arnaldo Carvalho de Melo]

On 5/29/07, John Anthony Kazos Jr. <jakj@j-a-k-j.com> wrote:
> > > > >   is there any rationale for setting a member of the file_operations
> > > > > structure explicitly to NULL as opposed to leaving it initialized?  i
> > > > > would think that's the default just based on the rules for C
> > > > > initialization, but i just wanted to make sure since i see it done
> > > > > every so often and wonder if there's something tricky going on that i
> > > > > don't know about.
> > > > >
> > > > > rday
> > > > >
> > > > >
> > > > Actually, C doesn't really care ... if you declare something, but don't
> > > > initialize it explicitly,
> > > > it will be filled with some random value (probably whatever was at the
> > > > given memory address
> > > > before C gave it to your var).
> > >
> > > Nope. If it is a global variable and it is left uninitialized it
> > > will be put into the .bss section and thus set to zero at program
> > > start.
> > >
> > > If you use named initializers in struct initializations, no matter
> > > where, the uninitialized members will be set to zero too.
> >
> > that's the understanding i had, so setting those global member fields
> > to NULL in various fops structures is really redundant.  doesn't hurt
> > anything, of course.
>
> Well, it does increase the on-disk image size. Like when code uses
> THIS_MODULE but is compiled built-in. But there're not many people who are
> going to really be interested in adding an ifdef to save that few bytes,
> unfortunately.

Yes, it used to be like that, but:

[acme@filo c_snippets]$ cat static.c
static int zero;

int main(void)
{
        printf("zero=%d\n", zero);
}
[acme@filo c_snippets]$ size static
   text    data     bss     dec     hex filename
   1005     252      12    1269     4f5 static
[acme@filo c_snippets]$

[acme@filo c_snippets]$ cat static.c
static int zero = 0;

int main(void)
{
        printf("zero=%d\n", zero);
}
[acme@filo c_snippets]$ size static
   text    data     bss     dec     hex filename
   1005     252      12    1269     4f5 static
[acme@filo c_snippets]$


So at least this version of gcc:

[acme@filo c_snippets]$ gcc --version
gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)

Seems to be smart enough about moving explicitily zero initialized
globals to .bss, see what happens if it is initialized to !zero:

[acme@filo c_snippets]$ cat static.c
static int zero = 1;

int main(void)
{
        printf("zero=%d\n", zero);
}
[acme@filo c_snippets]$ size static
   text    data     bss     dec     hex filename
   1005     256       8    1269     4f5 static
[acme@filo c_snippets]$

See the .bss size? 4 bytes less, and .data is 4 bytes bigger.

Even tho gcc now does this for us it is a quite common idiom not to
initialize to zero if it is a global.

- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Arnaldo Carvalho de Melo]

On 5/29/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Tue, 2007-05-29 at 10:55 -0400, John Anthony Kazos Jr. wrote:
> > > > > >   is there any rationale for setting a member of the file_operations
> > > > > > structure explicitly to NULL as opposed to leaving it initialized?  i
> > > > > > would think that's the default just based on the rules for C
> > > > > > initialization, but i just wanted to make sure since i see it done
> > > > > > every so often and wonder if there's something tricky going on that i
> > > > > > don't know about.
> > > > > >
> > > > > > rday
> > > > > >
> > > > > >
> > > > > Actually, C doesn't really care ... if you declare something, but don't
> > > > > initialize it explicitly,
> > > > > it will be filled with some random value (probably whatever was at the
> > > > > given memory address
> > > > > before C gave it to your var).
> > > >
> > > > Nope. If it is a global variable and it is left uninitialized it
> > > > will be put into the .bss section and thus set to zero at program
> > > > start.
> > > >
> > > > If you use named initializers in struct initializations, no matter
> > > > where, the uninitialized members will be set to zero too.
> > >
> > > that's the understanding i had, so setting those global member fields
> > > to NULL in various fops structures is really redundant.  doesn't hurt
> > > anything, of course.
> >
> > Well, it does increase the on-disk image size. Like when code uses
>
> The original question was about unused fields in (e.g.) struct
> file_operations.
> Are you sure your comment makes any sense then?

Original question:

----------------------------------- 8< --------------------------------------
is there any rationale for setting a member of the file_operations
structure explicitly to NULL as opposed to leaving it initialized?
----------------------------------- 8< --------------------------------------

It wasn't about _unused_ fields, was about _uninitialized_ fields. These
fields can be set to default values (function pointers with a fallback
implementation perhaps) at registration (or later) time.

If we forget about all the other issues about initialization that were
discussed (.bss, struct named fields initialization, garbage going into
uninitialized non global variables, etc) and stick to the original question
the answer, in my experience, would be:

1. Source code gets more cluttered if the not needed initialization to zero
   is used
2. if the field is removed from the struct, only the files that initialized it
    will have to be patched
3. the resulting binary is the same

- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Robert P. J. Day]

On Tue, 29 May 2007, Arnaldo Carvalho de Melo wrote:

> Original question:
>
> ----------------------------------- 8< --------------------------------------
> is there any rationale for setting a member of the file_operations
> structure explicitly to NULL as opposed to leaving it initialized?
> ----------------------------------- 8< --------------------------------------
                                                        ^^^^^^^^^^^

argh.  of course, in that original post, i meant "uninitialized", but
i'm guessing most people figured that out.

> It wasn't about _unused_ fields, was about _uninitialized_ fields.
> These fields can be set to default values (function pointers with a
> fallback implementation perhaps) at registration (or later) time.
>
> If we forget about all the other issues about initialization that were
> discussed (.bss, struct named fields initialization, garbage going into
> uninitialized non global variables, etc) and stick to the original question
> the answer, in my experience, would be:
>
> 1. Source code gets more cluttered if the not needed initialization to zero
>   is used
> 2. if the field is removed from the struct, only the files that initialized it
>    will have to be patched
> 3. the resulting binary is the same
>
> - Arnaldo

the only defensible rationale i can see for someone setting one of
those fields to NULL would be to visually emphasize that fact -- sort
of as a comment field.  but, in the end, it would of course make no
difference in the code.

-- 
====================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
====================================
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Arnaldo Carvalho de Melo]

On 5/29/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> On Tue, 29 May 2007, Arnaldo Carvalho de Melo wrote:
>
> > Original question:
> >
> > ----------------------------------- 8< --------------------------------------
> > is there any rationale for setting a member of the file_operations
> > structure explicitly to NULL as opposed to leaving it initialized?
> > ----------------------------------- 8< --------------------------------------
>                                                         ^^^^^^^^^^^
>
> argh.  of course, in that original post, i meant "uninitialized", but
> i'm guessing most people figured that out.
>
> > It wasn't about _unused_ fields, was about _uninitialized_ fields.
> > These fields can be set to default values (function pointers with a
> > fallback implementation perhaps) at registration (or later) time.
> >
> > If we forget about all the other issues about initialization that were
> > discussed (.bss, struct named fields initialization, garbage going into
> > uninitialized non global variables, etc) and stick to the original question
> > the answer, in my experience, would be:
> >
> > 1. Source code gets more cluttered if the not needed initialization to zero
> >   is used
> > 2. if the field is removed from the struct, only the files that initialized it
> >    will have to be patched
> > 3. the resulting binary is the same
> >
> > - Arnaldo
>
> the only defensible rationale i can see for someone setting one of
> those fields to NULL would be to visually emphasize that fact -- sort
> of as a comment field.  but, in the end, it would of course make no
> difference in the code.

I forgot about that rationale: "to stress that there is no
implementation for this method, use whatever is the default behaviour
for this operation".

But if that is the case better use a comment, more clear :-)

- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[John Anthony Kazos Jr.]

> > > > > >   is there any rationale for setting a member of the file_operations
> > > > > > structure explicitly to NULL as opposed to leaving it initialized?
> > i
> > > > > > would think that's the default just based on the rules for C
> > > > > > initialization, but i just wanted to make sure since i see it done
> > > > > > every so often and wonder if there's something tricky going on that
> > i
> > > > > > don't know about.
> > > > > >
> > > > > > rday
> > > > > >
> > > > > >
> > > > > Actually, C doesn't really care ... if you declare something, but
> > don't
> > > > > initialize it explicitly,
> > > > > it will be filled with some random value (probably whatever was at the
> > > > > given memory address
> > > > > before C gave it to your var).
> > > >
> > > > Nope. If it is a global variable and it is left uninitialized it
> > > > will be put into the .bss section and thus set to zero at program
> > > > start.
> > > >
> > > > If you use named initializers in struct initializations, no matter
> > > > where, the uninitialized members will be set to zero too.
> > >
> > > that's the understanding i had, so setting those global member fields
> > > to NULL in various fops structures is really redundant.  doesn't hurt
> > > anything, of course.
> > 
> > Well, it does increase the on-disk image size. Like when code uses
> > THIS_MODULE but is compiled built-in. But there're not many people who are
> > going to really be interested in adding an ifdef to save that few bytes,
> > unfortunately.
> 
> Yes, it used to be like that, but:
> 
> [acme@filo c_snippets]$ cat static.c
> static int zero;
> 
> int main(void)
> {
>        printf("zero=%d\n", zero);
> }
> [acme@filo c_snippets]$ size static
>   text    data     bss     dec     hex filename
>   1005     252      12    1269     4f5 static
> [acme@filo c_snippets]$
> 
> [acme@filo c_snippets]$ cat static.c
> static int zero = 0;
> 
> int main(void)
> {
>        printf("zero=%d\n", zero);
> }
> [acme@filo c_snippets]$ size static
>   text    data     bss     dec     hex filename
>   1005     252      12    1269     4f5 static
> [acme@filo c_snippets]$
> 
> 
> So at least this version of gcc:
> 
> [acme@filo c_snippets]$ gcc --version
> gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
> 
> Seems to be smart enough about moving explicitily zero initialized
> globals to .bss, see what happens if it is initialized to !zero:
> 
> [acme@filo c_snippets]$ cat static.c
> static int zero = 1;
> 
> int main(void)
> {
>        printf("zero=%d\n", zero);
> }
> [acme@filo c_snippets]$ size static
>   text    data     bss     dec     hex filename
>   1005     256       8    1269     4f5 static
> [acme@filo c_snippets]$
> 
> See the .bss size? 4 bytes less, and .data is 4 bytes bigger.
> 
> Even tho gcc now does this for us it is a quite common idiom not to
> initialize to zero if it is a global.

That's quite interesting, because I did my own test that was almost 
equivalent to yours, and mine actually did take it out of bss. I'm using 
4.1.3. Perhaps it was cosmic rays.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[Arnaldo Carvalho de Melo]

On 5/29/07, John Anthony Kazos Jr. <jakj@j-a-k-j.com> wrote:
> > > > > > >   is there any rationale for setting a member of the file_operations
> > > > > > > structure explicitly to NULL as opposed to leaving it initialized?
> > > i
> > > > > > > would think that's the default just based on the rules for C
> > > > > > > initialization, but i just wanted to make sure since i see it done
> > > > > > > every so often and wonder if there's something tricky going on that
> > > i
> > > > > > > don't know about.
> > > > > > >
> > > > > > > rday
> > > > > > >
> > > > > > >
> > > > > > Actually, C doesn't really care ... if you declare something, but
> > > don't
> > > > > > initialize it explicitly,
> > > > > > it will be filled with some random value (probably whatever was at the
> > > > > > given memory address
> > > > > > before C gave it to your var).
> > > > >
> > > > > Nope. If it is a global variable and it is left uninitialized it
> > > > > will be put into the .bss section and thus set to zero at program
> > > > > start.
> > > > >
> > > > > If you use named initializers in struct initializations, no matter
> > > > > where, the uninitialized members will be set to zero too.
> > > >
> > > > that's the understanding i had, so setting those global member fields
> > > > to NULL in various fops structures is really redundant.  doesn't hurt
> > > > anything, of course.
> > >
> > > Well, it does increase the on-disk image size. Like when code uses
> > > THIS_MODULE but is compiled built-in. But there're not many people who are
> > > going to really be interested in adding an ifdef to save that few bytes,
> > > unfortunately.
> >
> > Yes, it used to be like that, but:
> >
> > [acme@filo c_snippets]$ cat static.c
> > static int zero;
> >
> > int main(void)
> > {
> >        printf("zero=%d\n", zero);
> > }
> > [acme@filo c_snippets]$ size static
> >   text    data     bss     dec     hex filename
> >   1005     252      12    1269     4f5 static
> > [acme@filo c_snippets]$
> >
> > [acme@filo c_snippets]$ cat static.c
> > static int zero = 0;
> >
> > int main(void)
> > {
> >        printf("zero=%d\n", zero);
> > }
> > [acme@filo c_snippets]$ size static
> >   text    data     bss     dec     hex filename
> >   1005     252      12    1269     4f5 static
> > [acme@filo c_snippets]$
> >
> >
> > So at least this version of gcc:
> >
> > [acme@filo c_snippets]$ gcc --version
> > gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
> >
> > Seems to be smart enough about moving explicitily zero initialized
> > globals to .bss, see what happens if it is initialized to !zero:
> >
> > [acme@filo c_snippets]$ cat static.c
> > static int zero = 1;
> >
> > int main(void)
> > {
> >        printf("zero=%d\n", zero);
> > }
> > [acme@filo c_snippets]$ size static
> >   text    data     bss     dec     hex filename
> >   1005     256       8    1269     4f5 static
> > [acme@filo c_snippets]$
> >
> > See the .bss size? 4 bytes less, and .data is 4 bytes bigger.
> >
> > Even tho gcc now does this for us it is a quite common idiom not to
> > initialize to zero if it is a global.
>
> That's quite interesting, because I did my own test that was almost
> equivalent to yours, and mine actually did take it out of bss. I'm using
> 4.1.3. Perhaps it was cosmic rays.

You mean that in your test doing a initialization to 0 explicitly
makes the variable go to the .data section?

Indeed it may be a cosmic ray problem, its to damn cool down here, for
a brazilian, that is :-\ Will try in a x86_64 machine, better shielded
:-)

- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

Re: [KJ] setting fops member pointers to NULL?

[John Anthony Kazos Jr.]

> > > > > > > >   is there any rationale for setting a member of the
> > file_operations
> > > > > > > > structure explicitly to NULL as opposed to leaving it
> > initialized?
> > > > i
> > > > > > > > would think that's the default just based on the rules for C
> > > > > > > > initialization, but i just wanted to make sure since i see it
> > done
> > > > > > > > every so often and wonder if there's something tricky going on
> > that
> > > > i
> > > > > > > > don't know about.
> > > > > > > >
> > > > > > > > rday
> > > > > > > >
> > > > > > > >
> > > > > > > Actually, C doesn't really care ... if you declare something, but
> > > > don't
> > > > > > > initialize it explicitly,
> > > > > > > it will be filled with some random value (probably whatever was at
> > the
> > > > > > > given memory address
> > > > > > > before C gave it to your var).
> > > > > >
> > > > > > Nope. If it is a global variable and it is left uninitialized it
> > > > > > will be put into the .bss section and thus set to zero at program
> > > > > > start.
> > > > > >
> > > > > > If you use named initializers in struct initializations, no matter
> > > > > > where, the uninitialized members will be set to zero too.
> > > > >
> > > > > that's the understanding i had, so setting those global member fields
> > > > > to NULL in various fops structures is really redundant.  doesn't hurt
> > > > > anything, of course.
> > > >
> > > > Well, it does increase the on-disk image size. Like when code uses
> > > > THIS_MODULE but is compiled built-in. But there're not many people who
> > are
> > > > going to really be interested in adding an ifdef to save that few bytes,
> > > > unfortunately.
> > >
> > > Yes, it used to be like that, but:
> > >
> > > [acme@filo c_snippets]$ cat static.c
> > > static int zero;
> > >
> > > int main(void)
> > > {
> > >        printf("zero=%d\n", zero);
> > > }
> > > [acme@filo c_snippets]$ size static
> > >   text    data     bss     dec     hex filename
> > >   1005     252      12    1269     4f5 static
> > > [acme@filo c_snippets]$
> > >
> > > [acme@filo c_snippets]$ cat static.c
> > > static int zero = 0;
> > >
> > > int main(void)
> > > {
> > >        printf("zero=%d\n", zero);
> > > }
> > > [acme@filo c_snippets]$ size static
> > >   text    data     bss     dec     hex filename
> > >   1005     252      12    1269     4f5 static
> > > [acme@filo c_snippets]$
> > >
> > >
> > > So at least this version of gcc:
> > >
> > > [acme@filo c_snippets]$ gcc --version
> > > gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
> > >
> > > Seems to be smart enough about moving explicitily zero initialized
> > > globals to .bss, see what happens if it is initialized to !zero:
> > >
> > > [acme@filo c_snippets]$ cat static.c
> > > static int zero = 1;
> > >
> > > int main(void)
> > > {
> > >        printf("zero=%d\n", zero);
> > > }
> > > [acme@filo c_snippets]$ size static
> > >   text    data     bss     dec     hex filename
> > >   1005     256       8    1269     4f5 static
> > > [acme@filo c_snippets]$
> > >
> > > See the .bss size? 4 bytes less, and .data is 4 bytes bigger.
> > >
> > > Even tho gcc now does this for us it is a quite common idiom not to
> > > initialize to zero if it is a global.
> > 
> > That's quite interesting, because I did my own test that was almost
> > equivalent to yours, and mine actually did take it out of bss. I'm using
> > 4.1.3. Perhaps it was cosmic rays.
> 
> You mean that in your test doing a initialization to 0 explicitly
> makes the variable go to the .data section?
> 
> Indeed it may be a cosmic ray problem, its to damn cool down here, for
> a brazilian, that is :-\ Will try in a x86_64 machine, better shielded
> :-)

I tried it again. Worked fine this time. I have no idea what I did last 
time though. Hopefully I wasn't so completely stupid as to simply forget 
the -O2.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors