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

[Hitoshi Mitake]

At Mon, 29 Apr 2013 20:48:47 +0800,
Liu Yuan wrote:
> 
> 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.

Removing the RB_ROOT was overkill. This is my mistake. It can be
implemented like this under gnu99:
#define RB_ROOT { NULL }


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

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

Thanks,
Hitoshi