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

[Liu Yuan]

On 04/29/2013 09:26 PM, Hitoshi Mitake wrote:
> Removing the RB_ROOT was overkill. This is my mistake. It can be
> implemented like this under gnu99:
> #define RB_ROOT { NULL }
> 

Okay. If we don't pay price, then it is nice to have gnu-c99 with more
features.

> 
>> > 
>>>>> > >> > 
>>>>> > >> > 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.
> Dividing these switches into functoins and jump tables would be a
> better way, but it cannnot be optimal always. Because the local
> variables in original function should be passed as their
> parameters. If there are many local variables, we have to implement
> these functions which has many parameters, or declare them as global
> variables.
> 

I think it depends. Switch case is easier to write and concise enough to
handle bundle of function return cases. We can even write helper
functions for case handling if one is too big. But if we have more than
10 cases to handle and handling code is complex, it is always better to
use jump table to get neater code.

Speaking of too many local variables, I'd like to see it as a warn of
unstructured big functions which does poor abstraction and layering,
which is hard to understand and patch as more dependencies and
assumptions added as time go by. If we have to pass many variable
between functions, then it is better to group them as a struct rather
than plainly sharing them in a big function as local variables, this is
very much like sharing too many global variables between source files.

>> > 
>> > 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.
> Should these old platforms have GCC? We should prepare a package and
> distribute it for these platforms. The latest GCC is only required by
> platforms used by developers.

Okay, it makes sense to me

Thanks,
Yuan