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.
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.
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.
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).
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.
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.
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.
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?
> The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT
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.
That's the function definition, not its declaration. It's pre-ANSI C, so that semicolon can mislead. I didn't bother to grab the source to check whatever the header said (or, heh, didn't say, per OpenBSD convention), but I'm going to assume it was correct.
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.
Hm. This is the kind of thing where a compiler warning could be useful. I took a quick look at gcc's manual, but it does not seem to have a warning for this particular mistake (argument names do not match between declaration and definition).
That way, you could repeat yourself safely, since the repetition would be checked by the compiler.
To allow the function definition to serve as the single source of truth. That would be my guess. They simply don't want to have to update the parameter name at N places, if a parameter were to be renamed.
I love how frequently people on HN decry actual real working things people actually work on and use as "impractical". I suspect the combined experience of the entire openbsd team is greater than yours.
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);"
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.
On the other hand, my experience with BSD code is that it is completely unreadable. Linux has it a bit too, but in BSD there are way too many statements like "mst_fqd->f_do_skb((struct mfq_t *) q);"
Are there not examples where a statement is pretty much guaranteed to live on its own within a block? Having said that, my own style is to always include braces, for aesthetic reasons if nothing else.
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.
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.
Agreed, this is the very reason I created a small script [1] to install them on non-OpenBSD systems. They are excellent for as references when coding C and to check what is most likely a GNU extension when writing portable shell scripts.
50 comments
[ 4.0 ms ] story [ 102 ms ] threadLike the Linux kernel style, this is essentially K&R style, and the style most of Unix was written in.
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.
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.
"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.
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.
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.
On the other hand, my experience with BSD code is that it is completely unreadable. Linux has it a bit too, but in BSD there are way too many statements like "mst_fqd->f_do_skb((struct mfq_t *) q);"
sure
saves you a line, but it's a bug waiting to happen.https://www.imperialviolet.org/2014/02/22/applebug.html
-Wunreachable-code was disabled in gcc years ago.
[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).