On Fri, May 30, 2014 at 9:04 AM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
>
> On 5/30/2014 2:43 AM, Peter Dufault wrote:
>> On May 29, 2014, at 17:47 , Gedare Bloom <ged...@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.
-Gedare
>> Peter
>> -----------------
>> Peter Dufault
>> HD Associates, Inc. Software and System Engineering
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherr...@oarcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
