Re: [PATCH] mmc: USB SDIO/SD/MMC Host Controller (VUB300) driver Resubmission

[Tony Olech <tony.olech@elandigitalsystems.com>]

On Mon, 2011-01-24 at 09:43 -0500, Nicolas Pitre wrote:
> On Mon, 24 Jan 2011, Tony Olech wrote:
> > On Fri, 2011-01-21 at 16:14 -0500, Nicolas Pitre wrote:
> > > On Fri, 21 Jan 2011, Tony Olech wrote:
> > > > There are 5 "do not initialise statics" errors reported by scripts/checkpatch.pl
> > > 
> > > you probably should fix those.  They are due to lines such as:
> > > 
> > > static int pad_input_to_usb_pkt = 0;
> > > static int disable_offload_processing = 0;
> > > static int force_1_bit_data_xfers = 0;
> > > static int force_polling_for_irqs = 0;
> > > 
> > > Since those are global variables, you may omit to initialize them to 0 
> > > which would then allocate them to the .bss section which is not included 
> > > in the compiled binary, and automatically cleared to zero at run time
> > > Nicolas
> > Yes they are due to exactly that, BUT I  have a great aversion to using
> > uninitialized variables. How can initializing all one's variables be
> > considered a bug????
> 
> Let me repeat myself.
> 
> 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. How then can one do static code analysis
to determine which uninitialized variables are uninitialized as
a result of a bug?
Tony Olech