-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Timur Tabi Sent: Thursday, April 09, 2009 1:55 AM To: Jerry Van Baren Cc: U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren gerald.vanbaren@ge.com wrote:
ACK. I don't expect to see variables spring into life in
the middle of
nowhere.
I don't see what's wrong with that. The advantage is that the variable is close to where it's being used, so that you can see the context more easily.
If I'm not confused, I've seen block-local u-boot variables, has the advantages of being more distinctive and limits the lifetime of the variable.
I don't see what the value is of limiting the lifetime of the variable. The compiler isn't going to use that as a hint, anyway. It's just going to use this for syntax checking. If you define and initialize a variable at the top of the function, but don't use that variable until a hundred lines later, the compiler is going to initialize the variable when it's first used, not when the function is first entered. Chances are it's not even going to define stack space for it.
One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc.
I feel, here, ifdefs provide a false sense of 'enclosure' with possibility of frequent breaches - in code (while implementing) and in simple reading (for understanding).
~sanjeev
#ifdef CONFIG_COOL_FEATURE { u32 myvarrocks = foo * bar * bar;
gd->neato = myvarrocks } #endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
-- Timur Tabi Linux kernel developer at Freescale _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot