On Mon, 2011-01-24 at 10:55 -0500, Nicolas Pitre wrote:
> On Mon, 24 Jan 2011, Tony Olech wrote:
> 
> > On Mon, 2011-01-24 at 09:43 -0500, Nicolas Pitre wrote:
> > > Uninitialized global scope variables are by definition assigned to the 
> > > .bss section.  The .bss section is dynamically allocated at run time 
> > > rather than being stored in the compiled binary, and also cleared to 
> > > zero at run time.  So the preference is for zero-initialized global 
> > > variables not to be initialized at all because 1) they are implicitly 
> > > initialized to zero anyway, and 2) that makes the resulting binaries 
> > > smaller.
> > > So this is not about fixing a bug, but rather to conform to the adopted 
> > > policy for kernel code.
> > > Nicolas
> > Thanks for the reply. I had not realized that saving 20 bytes on the
> > binary size was so important.
> With the size of the kernel they add up.
> > How then can one do static code analysis
> > to determine which uninitialized variables are uninitialized as
> > a result of a bug?
> A good static code analysis tool should know already that uninitialized 
> global variables are implicitly initialized to zero.  This is not the 
> case for local variables of course
> Nicolas
Thanks for the reply.
I had assumed that for a module the global initialized variables were
loaded at module load. That then is a problem given that new devices
(and drivers) are appearing quite rapidly. I therefore do not understand
how the global initialized variables from an externally compiled kernel
module get added into the kernel image - does "depmod" do that?
A good static code analysis tool surely can only show a list of
uninitialized static global variables leaving it for the user to
trawl through and decide which are OK and which are not - so much
easier if one has no uninitialized static global variables to start
with.
Tony Olech


--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to