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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
