
Making C Less Dangerous in the Linux Kernel [video] - reddotX
https://www.youtube.com/watch?v=FY9SbqTO5GQ
======
steelframe
Kees is one of the few developers in the world doing the boots-on-the-ground
rough-and-tumble soul-withering grunt work of actually making Linux kernel
more secure. It's not glorious work, but it's perhaps the most important work
anyone's doing in the kernel these days. The world runs on the Linux kernel,
and from a security standpoint, it's really been a mess (see: Dmitry's
Syzkaller talk). Too many contributors are drive-by scattershot "my boss told
me to upstream this stuff" types who don't really care about the incremental
suckage they inject into the kernel. Bravo on Kees for doing what he's doing.

~~~
pjmlp
Indeed and that is why I mostly criticise C, we need solid foundations and
UNIX clones aren't going anywhere for the foreseeable future.

So whatever can be done in a safer languages should be, and for use cases like
this we really need to improve what actually means to use C.

Linux is a very good example that even with quality gates, safety errors creep
in and something has to be done about it.

Really kudos to Kees and everyone else involved on these projects.

------
FartyMcFarter
There's a misleading statement in the "undefined behavior" slide. Allow me to
nitpick, since this subject is so full of misunderstandings and confusion.

"What are the contents of uninitialized variables? ... whatever was in memory
before now!"

This may be true or false - as the slide itself says, "with undefined
behavior, anything is possible!".

Besides, the subject of accessing uninitialized variables is more nuanced than
"undefined behavior". Among other things, the effects depend on the variable's
type ("unsigned char" does not have trap values):

[https://stackoverflow.com/questions/11962457/why-is-using-
an...](https://stackoverflow.com/questions/11962457/why-is-using-an-
uninitialized-variable-undefined-behavior)

[https://stackoverflow.com/questions/6725809/trap-
representat...](https://stackoverflow.com/questions/6725809/trap-
representation)

It's also important to note that C++ has different rules on this. For example,
the extract_int function in the last link is valid C, but not valid C++ (in
C++ you'd use std::memcpy to achieve the same thing in a valid way).

~~~
pjmlp
Also to note that ISO C++ working group is trying to reduce the amount of UB,
while ISO C working group doesn't have any ongoing papers into this direction.

------
greesil
I didn't even know that scnprintf was a thing. Cool! I learned something just
by skimming the video

~~~
ddtaylor
I think the presenter mentions it's only in Linux kernel though, not available
in userspace.

~~~
chacham15
The userspace version is snprintf.

~~~
aboutruby
The speaker mentions it, seems like the return value is different:
[https://i.imgur.com/Jj2fMZu.png](https://i.imgur.com/Jj2fMZu.png)

~~~
Taniwha
yes - snprintf() returns the length of the string that would be written even
if it wasn't clipped to the length of the output buffer - if you want to
accumulate strings into a buffer using the output length to update the
offset/size bad things will happen.

scnprintf() returns the actual number of bytes written (less the null)

