[OpenAFS-devel] Fwd: [patch review] libafs solaris cleanup

[Marcus Watts]

Garance Alistair Drosehn writes:
...
> For what it's worth, sometime in my early freebsd days it was
> explained to me that 'return (blah)' is preferred simply because
> it makes it easy to replace 'return' with a #define'd macro, if
> you needed to do that for some debugging reason.
> 
> However, as others have said, it was also stressed to me that
> cosmetic changes should be done as separate commits, and not mixed
> in with real-changes to the source code.  It adds a bunch of
> necessary work for anyone trying to review the patch -- which may
> include people looking through the CVS history for a given file.
> It's so much easier if you can say "Yes, there are 10,000 lines
> changed in this commit, but the object-code is exactly the same
> after this commit as it was before the commit.  If you're looking
> for some subtle bug which sneaked in during the past five years,
> then it did not happen with this commit!"

Ok, sure, for some sufficiently simple program
	#define bug(x) printf ("__FILE__:__LINE__ return %#lx\n",(x)),(x)
	main(){
		return (5);
	}
you could compile it with
	cc -Dreturn=bug
or with just cc

I don't think anybody is ever going to do anything remotely
like this with openafs.  Just for starters, you'd have to rely
on return falling off the end of the function and returning the
last expression evaluated.

I've always thought that return() was leftover from b or bcpl syntax.
In bcpl it's "RESULTIS" - no () required.  Looks like b requires () though,
so I think that's the origin of this convention.  bcpl supports "get"
and "manifest", but I haven't found any mention of "#include" or
"define" for b.  I assume they put () in for symmetry with while/if,
then omitted it in c's definition when they realized it wasn't necessary,
but kept on using () anyway out of inertia.

I leave () off habitually for return; because I don't think they
contribute at all to readability.  All other things being equal,
the less "noise" there is, the more obvious the remainder will be.
I don't much care if other folks use (), but I hope they don't
go tearing off on some expedition to add or remove them.

An even more interesting case of this is the "sizeof" operator.
It can be used this way:
	sizeof(type)
	sizeof expr
I use the second form by preference.  For instance,
	struct foo *xp;
	xp = malloc(sizeof *xp);
if somebody else changes xp to be a "struct bar", only the dcl
has to change.  Leaving () off forces this to be unambigious; consider
this contrived example:
	#include <stdlib.h>
	typedef struct list {int a, b, c;} list[5];
	main(){ struct list *list; list = malloc(sizeof(list)); }
(this actually is unambiguous -- to the compiler.)

				-Marcus Watts