OpenBSD kernel source file style guide
openbsd.org
openbsd.org
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.
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.
diff --git a/drivers/staging/unisys/include/timskmod.h b/drivers/staging/unisys/include/timskmod.h
index b20fc9d..59144ba 100644
--- a/drivers/staging/unisys/include/timskmod.h
+++ b/drivers/staging/unisys/include/timskmod.h
@@ -293,6 +293,7 @@ static inline struct cdev *cdev_alloc_init(struct module *owner,
const struct file_operations *fops)
{
struct cdev *cdev = NULL;
+
cdev = cdev_alloc();
if (!cdev)
return NULL;
1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
So yeah, on staging you can expect to see lots of non-functional changes, mixed with functional changes.
Like the Linux kernel style, this is essentially K&R style, and the style most of Unix was written in.
[1]: https://github.com/ninjin/ppod/tree/master/hck/openbsd_manpa...
On the Linux side, Debian tends to support manpages better than others (they're required by Policy, though they're not release-critical).
sure
for ()
foo
-Wunreachable-code was disabled in gcc years ago.
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..
}
The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT, and of course completely irrelevant because you can make that mistake regardless of what the header says.
Parameters in headers are just documentation, by definition. Documentation can be wrong however you write it, but in general it helps to have it instead of not. Would you seriously argue that function parameters should not be given names in documentation?
Actually if you look at the patch to fix this issue, they swap the identifiers in the declarator. Of course when something like this happens, you're free to choose whether the definition or the callers should be changed.
https://www.FreeBSD.org/security/patches/SA-14:11/sendmail.p...
It amuses me greatly that we're sitting here arguing over the minutiae of coding standards when this thing is still written in K&R syntax.
But regardless: whatever the header said, it wouldn't have affected this bug, which was just a straightforward transpose thing between compatible types. People get memcpy() reversed all the time too, and frankly I don't know if I've ever looked at its function declaration in a header.
That way, you could repeat yourself safely, since the repetition would be checked by the compiler.
void<tab>function(int);