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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
