[sheepdog] [PATCH RFC] employ gnu99 style of GCC

[Liu Yuan]

On 04/29/2013 08:38 PM, Hitoshi Mitake wrote:
> Of course I don't say variable declarations is the most important
> problem for source code readability. Its role is very little. But I
> strongly believe that variables with narrow scope can contribute to
> the readability. e.g. If we write a variable used as an index in an
> initializatoin part of for statement like this: for (int i = 0; ...),
> we can forget about the variable when we are focusing on the outside
> of the loop.
> 

for (int i = 0; ...) might looks a nice candy but seems your RFC romove
'RB_ROOT', which is very handy macro. I take this as a price to pay.

>> > 
>> > Most of time it is always easier to add statements into an existing
>> > functions to add more features or fix bugs, or just lazy to add helpers
>> > to abstract away the details because at the time one might think it is
>> > obvious to put it in a big function. Many reasons contribute to the
>> > bloated and hard-to-understand functions, but not the variable
>> > declaration. If we always have functions smaller than, say 30 lines
>> > (this is quite theoretical and just take it as a optional target), I
>> > don't think we'll have problems that your patch aims to solve.
>> > 
>> > So instead of playing with variables, we are better off if we fix the
>> > problems from the ground that if some functions doesn't looks
>> > self-explanatory and complex with too many lines, parameters, variables,
>> > it is the time to put it in a bigger picture and re-structure them.
> Keeping each functions short and clean is one of the most important
> thing for readability. Of course I don't disagree with this
> opinion. But functions with less than 30 lines is not a realistic
> target. e.g. sheep/cluster/corosync.c has some big switch statements
> and they would be optimal forms.

So if the rule applies to switch case, I think it should be rephrased as
each case handling should be less than 30 lines. If many case handling
break this rules, we should use function pointer approach instead.

One more question, does RHEL 5 support GNU-C99 fully? And other platform
such as old debian, you know, many servers in production is very
conventional and impossible to upgrade GCC.

Thanks,
Yuan