rtems/src/scheduler* code convention issue

[Joel Sherrill]

On 5/30/2014 2:43 AM, Peter Dufault wrote:
> On May 29, 2014, at 17:47 , Gedare Bloom <gedare at rtems.org> wrote:
>
>> You understood precisely. I think it was not permitted in C90 perhaps?
>> We should revisit it, but I think historically all variables are
>> declared at the top of the function.
> I'll dig up K&R, but I'm 95% sure it's been supported from the beginning.  What hasn't always been supported is declaring variables anywhere other than after an opening bracket:
>
> /* Local block */
> {
> 	invoke_foo();
> 	int i;
> 	invoke_bar(&i);
> 	/* ... */
> }
>
> The argument for permitting declaration inside brackets (not as above, but as allowed by K&R) is to declare variables in as restrictive a scope as possible.  The argument against is shadowing variables and getting subtle errors.
I don't know if we have it on but gcc has a shadowing warning which
is pretty effective. I did a code review for a project and learned they
had disabled warnings "because there were too many." When I turned
them back on, there were 1000s and among them:

+ parameters shadowing global variables.
+ outer scope local variables shadowing global variables.
+ inner scope local variables (from macros) shadowing local variables

GCC spotted all of the above. I am pretty confident in GCC's shadowing
detection.  If we want to allow/encourage this, we need to turn
the warning on.

Also we need to remember to write down that macro parameters
start with an _ so as to avoid name collision. The project I reviewed
didn't follow that rule.  They also didn't have naming rules which
prevented collisions between local, global, and parameters.
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985