sure
for ()
foo
for () foo;
"In function prototypes, include parameter names with their data types. Although this is not required by the C language, it is preferred in Linux because it is a simple way to add valuable information for the reader."
OpenBSD enforces this:
"Prototypes should not have variable names associated with the types; i.e., void function(int); not: void function(int a);"
Instead of letting the code tell the parameters' purposes, this now has to be deduced from informal descriptions, or the function definition in some .c file.
//decl in the header
int pow(int exponent, int base);
//actual definition
int pow(int base, int exponent){
//math is correct but base <-> exponent..
}
That way, you could repeat yourself safely, since the repetition would be checked by the compiler.
https://www.kernel.org/doc/Documentation/CodingStyle
Example: Why is the comment style different in net/? It seems to serve no obvious purpose.
Too many cooks :-)
These non-functional commits happen more in areas under active development, while established and inactive projects with less than enough watching eyes want to avoid this kind of non-essential changes.
On the Linux side, Debian tends to support manpages better than others (they're required by Policy, though they're not release-critical).
[1]: https://github.com/ninjin/ppod/tree/master/hck/openbsd_manpa...
void<tab>function(int);
However, I've only had horrible experiences trying to read the BSDs' kernel code. There are way too many statements like "mst_fqd->f_do_skb((struct mfq_t *) q);"
sys/queue.h is also provided in all Linux systems.
Easy to use, type-checked by the compiler and a lot faster than a "generic" linked list with pointers to the data. Here, the next/previous pointers get embedded in the payload struct itself.
Like the Linux kernel style, this is essentially K&R style, and the style most of Unix was written in.