[systemd-devel] [PATCH 2/2] hashmap.h: fix coding style issue

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 26, 2013 at 07:42:34PM +0100, Simon McVittie wrote:
> On 26/04/13 18:49, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Apr 26, 2013 at 06:40:08PM +0200, Daniel Buch wrote:
> >> -void* hashmap_get(Hashmap *h, const void *key);
> >> -void* hashmap_get2(Hashmap *h, const void *key, void **rkey);
> >> +void *hashmap_get(Hashmap *h, const void *key);
> >> +void *hashmap_get2(Hashmap *h, const void *key, void **rkey);
> > 
> > I find the updated version actually harder to read. We seem to consistently
> > use 'char* xxx()', and 'void* xxx' is more common than 'void *xxx'.
> 
> I believe the reason that many C projects prefer "T *v" over "T* v" is
> that for the case where v is a variable (as opposed to a function name
> or a parameter) that's how the precedence works in C syntax: if you declare
> 
>     int *x, y;
> 
> then x is a pointer-to-int but y is an int (you can also think of it as
> "*x and y are ints"). If you do the whitespace like this
> 
>     int* x, y;
> 
> then the semantics are identical, and the whitespace is misleading: the
> obvious interpretation suggested by the whitespace is that both x and y
> are pointer-to-int, but it isn't actually true.
Right, but this doesn't apply to functions, since there's just one
per line.

> The coding styles "don't declare pointer-to-foo variables on the same
> line as foo variables" and "don't declare multiple variables per line at
> all" also avoid that problem, of course. I personally think multiple
> variables per line are suspicious, and multiple variables of differing
> "pointer-ness" on the same line are the sort of thing that's only valid
> in obfuscated C competitions, but opinions vary...
Well, thankfully this doesn't apply to systemd, because it'd mean that
some of our files would get substantially longer.

Zbyszek