Re: C99: Suggestions for style(9)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 01 May 2009 14:02:50 +0200
Christoph Mallon <christoph.mallon@xxxxxx> mentioned:

[Don't parenthesize return values]
Removed, because it does not improve maintainability in any way.

This change could be made and tested mechanically. But there is
no justification for making it - stating that the existing rule
is no better than the proposed rule is no reason to change.

Just remove the rule. There's no need to add more redundant parentheses.
Again: There is no need to change all existing code at once, but the
rule is removed so that not anymore redundant parentheses are added.

If only the rule gets removed this will lead to inconsistent code. Currently
it is much easier to experienced leader to notice return statements with
parenthesis around the value than without. Recall that people's eyes are
build in way that they recognized entire expressions and not letter
combinations.

[ Don't insert an empty line if the function has no local variables.]

This change could be made and tested mechanically. IMHO, this change
has neglible risk and could be safely implemented.

Again: No need for immediate global change, but just do not add anymore
of those. There are already quite some functions, which do not have the
unnecessary empty line.


What seems to you as unnecessary rule may be of a great use for other
code users. For me it improves the code readability as an empty line
at the start clearly points that there're no local variables used. I
don't see enough argumentation for removing this rule.

+.Sh LOCAL VARIABLES

Last, but definitely not least, I added this paragraph about the use of
local variables. This is to clarify, how today's compilers handle
unaliased local variables.

Every version of gcc that FreeBSD has ever used would do this for
primitive types when optimisation was enabled. This approach can
become expensive in stack (and this is an issue for kernel code) when
using non-primitive types or when optimisation is not enabled (though
I'm not sure if this is supported). Assuming that gcc (and icc and
clang) behaves as stated in all supported optimisation modes, this
change would appear to be quite safe to make.

Most local variables are scalars (pointers, ints, ...). A struct or
array as local variable is rare and then usually used in one context. So
IMO this is fine. Even considereing the extremly rare case of multiple
non-scalar declarations in a function, then a compiler can coalesce them
if their life ranges are disjoint. It is easier to do so for a compiler
to do so, if they are declared with smaller life ranges, example:

struct Foo { int x[16]; };
struct Bar { int* y[16]; };

void f(struct Foo*);
void g(struct Bar*);

void e(int x)
{
struct Foo a;
struct Bar b;
if (x) {
f(&a);
} else {
g(&b);
}
}

Stack usage:
subl $140, %esp

moving the declarations into the branches:
subl $76, %esp

So, apart from improved readability, it also can lead to better code.
But I consider the latter way less important the benefits observed by a
reader of the code.


I particulary like this change. Aliasing behavior is stritcly described in
ISO C99 standard, so there's a good point to enforcing strict-aliasing clear
code in our kernel. On the other hand the big work should be done on clearing
the existing code before any rule on this can be enforced.

- --
Stanislav Sedov
ST4096-RIPE
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkoP6rwACgkQK/VZk+smlYHdAACeJo64Mc0syCLtXq93yg0f87Y7
T2kAn1gLof6OMcHHs3EbRYTx7QE5NwU8
=5waq
-----END PGP SIGNATURE-----

!DSPAM:4a0fea9d994295559415935!


_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: C99: Suggestions for style(9)
    ... There's no need to add more redundant parentheses. ... Last, but definitely not least, I added this paragraph about the use of local variables. ... Even considereing the extremly rare case of multiple non-scalar declarations in a function, then a compiler can coalesce them if their life ranges are disjoint. ... void f; ...
    (freebsd-hackers)
  • Re: Question about a cast
    ... void * first; ... struct pipe_data_list { ... lists without scanning them. ... much like sticking declarations in the middle of code. ...
    (comp.lang.c)
  • Re: C99: Suggestions for style(9)
    ... This change is to reduce the scope of local variables. ... More local variables cost nothing, especially no stack space, ... It also enables the compiler to produce better warnings: ... You can determine the stack usage with all the variable declarations ...
    (freebsd-hackers)
  • Re: fields for methods?
    ... than one method on a "Brush" object: ... void change_color; ... Sure, "encapsulation" is a buzzword with many competing definitions, ... the same as static local variables because static local variables are like ...
    (comp.programming)
  • Re: C99: Suggestions for style(9)
    ... cost as maintainers switch between styles. ... E.g. you should never use K&R declarations when adding a new function. ... how today's compilers handle:>unaliased local variables. ... primitive types when optimisation was enabled. ...
    (freebsd-hackers)
Loading