
OpenBSD kernel source file style guide - zytek
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style&arch=i386
======
bjackman
I've never written code with it, but the BSDs use these macros to implement
rudimentary generic types in C: [http://www.openbsd.org/cgi-
bin/man.cgi/OpenBSD-current/man3/...](http://www.openbsd.org/cgi-
bin/man.cgi/OpenBSD-current/man3/LIST_EMPTY.3?query=queue&sec=3&arch=i386).
Nice.

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);"

~~~
jpfr
Yes! That's a really good implementations of linked lists using only
preprocessor macros.

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.

------
feld
Linux's is very long in comparison to the BSD's. It seems to have weird edge-
cases and possibly unnecessary explanations.

[https://www.kernel.org/doc/Documentation/CodingStyle](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 :-)

~~~
Alupis
Likely because /net was done before the coding standard and by some 3rd party
contributor -- and doing non-functional whitespace/formatting commits is a no-
no in most large projects.

~~~
xfs
Linux kernel does have a lot of non-functional formatting commits.
[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=formatting)

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.

~~~
Alupis
the link you provided has no "just formatting only" changes. The non-
functional changes you see there are updating documentation in comments. That
is a big difference. You won't ever see "i just felt like we should have an
extra blank line here" changes.

~~~
3JPLW
Hunh? Try the _staging: unisys: fix formatting in timskmod.h_ patch -
e5700df52 [1]

    
    
        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;
    
    

(This commit just happened to be the only one I peeked at from the link above
- and is particularly apropos)

1\.
[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5700df5238577e4e570d08a8ee1aa126731dae7)

~~~
Alupis
well i stand corrected it seems. although if that is from staging, then it
will likely get squashed before merged into mainline (meaning this commit
won't actually stay in the history).

~~~
cesarb
Staging is an exception. Staging is a place to put low-quality drivers
developed outside the Linux kernel community, to be fixed to Linux kernel
standards before being moved into the normal tree. One of the many things done
to a driver in staging is to fix the source code formatting. The commits won't
get squashed, since it's part of the mainline git repository, which is never
squashed.

So yeah, on staging you can expect to see lots of non-functional changes,
mixed with functional changes.

------
kps
The first published BSD KNF can be found various places including here:
[https://stuff.mit.edu/afs/athena/astaff/reference/4.4lite/us...](https://stuff.mit.edu/afs/athena/astaff/reference/4.4lite/usr/src/admin/style/style)

Like the Linux kernel style, this is essentially K&R style, and the style most
of Unix was written in.

------
gcb0
openbsd is the only project which manpages are not mostly useless. You have
even a starting guide there.

~~~
dredmorbius
FreeBSD's manpages are also quite excellent. I haven't had to refer to
NetBSD's but I'd suspect it's also good.

On the Linux side, Debian tends to support manpages better than others
(they're required by Policy, though they're not release-critical).

------
ja30278
I never understand the desire to omit braces in single line blocks.

sure

    
    
       for ()
           foo
    

saves you a line, but it's a bug waiting to happen.

~~~
DrJokepu
People keep saying that, but do bugs like that really happen? In my entire
career as a professional software developer I've never seen it happening. Not
once.

~~~
hobo_mark
Oh yes it does.

[https://www.imperialviolet.org/2014/02/22/applebug.html](https://www.imperialviolet.org/2014/02/22/applebug.html)

~~~
DrJokepu
Fair enough. That being said, -Wunreachable-code would have caught that.

~~~
coolsunglasses
>Fair enough. That being said, -Wunreachable-code would have caught that.

-Wunreachable-code was disabled in gcc years ago.

~~~
DrJokepu
Yes, but I would assume that Apple uses clang internally?

------
mheiler
I like that it's short.

------
bigfoot
Archaic and impractical. Example: Instead of using Linux' pragmatic approach
to function prototypes:

"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.

~~~
0x0
What would be a reason for leaving out the parameter names? Genuinely curious.

~~~
foxhill
DRY principle - you give the variables a name once, in the function
definition. e.g:

    
    
        //decl in the header
        int pow(int exponent, int base);
    

if you only look at the header you might think that the arguments are one way,
but

    
    
        //actual definition
        int pow(int base, int exponent){
          //math is correct but base <-> exponent..
        }
    

i'm not saying i agree with this at all - it's a contrived example..!

~~~
tedunangst
CVE-2014-3956

~~~
erhardm
Replying with a CVE is like icing on the cake. :) It really shows that OpenBSD
devs take security seriously. Funny timing, I was just reading Absolute
OpenBSD.

~~~
steveklabnik
It also demonstrates that sometimes, there are additional constraints that you
may not understand in choices you may not agree with.

------
JelteF
This is the first time I've heard of a style guide that demands a mixture of
tabs and spaces. I thought this was very much frowned upon.

~~~
Negitivefrags
Tabs for indentation, spaces for alignment. This is the only sane standard.

~~~
huhtenberg
I still find it discomforting that it mandates the use of tabs in the middle
of the line -

    
    
      void<tab>function(int);
    

A cleaner option is "tabs for indentation, spaces for alignment", but with
tabs allowed at the beginning of line _only_. This way opening a file in an
editor with a different tab size will still preserve the alignment of the
parts.

------
fredmorcos
Here's a question, since the man page mentions splint. Has anyone here ever
managed to reach a splint warning-free project?

