rtems/src/scheduler* code convention issue

Gedare Bloom gedare at rtems.org
Fri May 30 13:13:18 UTC 2014

On Fri, May 30, 2014 at 9:04 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> 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.
Thanks for the discussion on this. I will put a rule as declaring
variables at the start of a block, and not to shadow variables.

Whether we want to encourage variables in nested scopes remains open
for discussion, but I think we should allow it at least.

> 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.
I'll add a note about it.

>> 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

More information about the devel mailing list