svn commit: r197407 - in head/sys: kern sys

Bruce Evans brde at optusnet.com.au
Tue Sep 22 20:08:24 UTC 2009


On Tue, 22 Sep 2009, Roman Divacky wrote:

> Log:
>  Change unsigned foo to u_foo as required by style(9).
>
>  Requested by:	bde
>  Approved by:	ed (mentor)

Thanks.

style(9) actually doesn't require this, even by example (it has zero examples
of u_foo and zero examples of `unsigned', except to say to use C99 uintXX_t
instead of old BSD u_intXX_t).  Examples from non-broken versions:

4.4BSD-Lite /usr/src/admin/style/style:
% 	/*
% 	 * When declaring variables in functions declare them sorted by size,
% 	 * then in alphabetical order; multiple ones per line are okay.  Old
% 	 * style function declarations can go on the same line.  ANSI style
% 	 * function declarations should go in the include file "extern.h".
% 	 * If a line overflows reuse the type keyword.
% 	 *
% 	 * DO NOT initialize variables in the declarations.
   	      ^^^ also broken in FreeBSD
% 	 */
% 	extern u_char one;
   	       ^^ (`one' and other variables have unrelated types now)
% 	extern char two;
% 	struct foo three, *four;
% 	double five;
% 	int *six, seven, eight();
% 	char *nine, ten, eleven, twelve, thirteen, fourteen, fifteen, sixteen;
% 	char *overflow __P((void));
% 	void *mymalloc __P((u_int));
   	                    ^^
NetBSD /usr/src/share/misc/style (style,v 1.30 2005/02/02... at least):
% 	/*
% 	 * When declaring variables in functions declare them sorted by size,
% 	 * then in alphabetical order; multiple ones per line are okay.
% 	 * Function prototypes should go in the include file "extern.h".
% 	 * If a line overflows reuse the type keyword.
% 	 *
% 	 * DO NOT initialize variables in the declarations.
% 	 */
% 	extern uint32_t zero;
% 	extern u_char one;
% 	extern char two;
% 	struct foo three, *four;
% 	double five;
% 	int *six, seven;
% 	char *eight, *nine, ten, eleven, twelve, thirteen;
% 	char fourteen, fifteen, sixteen;

FreeBSD version for comparison (style.9,v 1.110 2004/07/03 ... at least):
% .Pp
% When declaring variables in functions declare them sorted by size,
% then in alphabetical order; multiple ones per line are okay.
% If a line overflows reuse the type keyword.
% .Pp
% Be careful to not obfuscate the code by initializing variables in
% the declarations.
% Use this feature only thoughtfully.
% DO NOT use function calls in initializers.
% .Bd -literal
% 	struct foo one, *two;
% 	double three;
% 	int *four, five;
% 	char *six, seven, eight, nine, ten, eleven, twelve;

Also lost example of "reuse the type keyword".

% 
% 	four = myfunction();

I prefer the NetBSD version with some modifications:

% 	/*
% 	 * When declaring variables in functions declare them sorted by size,

Sort on alignment, not size; if alignment isn't known, then sort on type
first, with complicated rules for sorting on type (some examples below).

% 	 * then in alphabetical order; multiple ones per line are okay.

Use the same sorting rules as for structs though the order doesn't matter
here.  [Don't repeat the details of the rules here.]

% 	 * Function prototypes should go in the include file "extern.h".

Except most functions should be static.

% 	 * If a line overflows reuse the type keyword.

[Bug: declarations weren't always keywords even before typedefs existed.]

If a line would be longer than the maximum line length (as not yet documented
here), then start a new line, repeating the type declaration.

% 	 *
% 	 * DO NOT initialize variables in the declarations.
% 	 */
% 	extern uint32_t zero;

Put a struct first, as in the FreeBSD version.

% 	extern u_char one;
% 	extern char two;

Don't permit extern declarations in blocks, as in the FreeBSD version.

Putting char variables first violates NetBSD's own rule on sorting by
size.  The rule shouldn't apply to externs, but it doesn't distinguish
externs from locals.

% 	struct foo three, *four;

My type-sorting rule doesn't permit mixing pointers with non-pointers.

NetBSD's size-sorting rule only permits mixing pointers with non-pointers
if the size of the non-pointer is the same as the size of the pointer, or
if the rule is misread as being about the size of the part of the type
without the '*'.

% 	double five;
% 	int *six, seven;

Even for ints, the relative sizes are unknown and/or machine-dependent.
My rules would put all pointers before all ints, and this happens to
give sorting on both size and alignment on all arches supported by FreeBSD
(ILP32 and I32LP64).

% 	char *eight, *nine, ten, eleven, twelve, thirteen;

chars are smaller than pointers on most arches and have less than or equal
to alignment requirements on all arches, so this example clearly violates
NetBSD's own sorting-on-size rule.  It also violates the alpha-sorting rule
(ten > eleven, although 10 < 11, etc.).  In fact, about half of the examples
violate the alpha-sorting rule in the same way, starting with (three > four,
although 3 < 4).  This bug is mostly due to poorly-chosen variable names.

% 	char fourteen, fifteen, sixteen;

There are too many examples with the same type and of mixing pointers with
non-pointers.  Even if the mixing were allowed, 1 example of it would be
enough.

NetBSD decls sorted by my rules:

/* In header file: */
extern uint32_t zero;
extern u_char one;
extern char two;

 	struct foo three;	/* structs first */
 	stuct foo *four;	/* then pointers to structs */
 	int *six;		/* then other pointers... */
 	char *eight, *nine;	/* pointers to least-strict-aligned objs last */
 	double five;		/* then FP scalars */
 	int seven;		/* then integers (typedefed ones first, no ex)*/
 	/* u_chars before chars no example */
#ifdef TOTALLY_DISORDERED_DONT_DO_THIS
 	char ten, eleven, twelve, thirteen;	/* violation of alpha order */
 	char fourteen, fifteen, sixteen;	/* example of "keyword reuse" */
#else
 	char eleven, ten, thirteen, twelve;	/* required alpha order ... */
 	char fifteen, fourteen, sixteen;	/* ...is unhelpful here  */
#endif

The last variables could be named something like v10, v11, ... v16 so that
actually following the sorting rules doesn't give an unreadable order.

Bruce


More information about the svn-src-all mailing list