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

[Simon McVittie]

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.

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

    S