Rust Developers Move Ahead With Preparing To Upstream More Code Into The Linux Kernel

[moltonel]

afaik there is no "other kernel code". Rust will not be in the kernel at all, there are no plans for that currently.

Huh ? Rust in 6.1 is very limited, but the 6.2 PR has interfaces to network and filesystem in addition to pure driver stuff. The longterm goal is to be able to use Rust almost anywhere in the kernel, even if it remains out of mainline for various reasons. Also, Rust is already a popular language to write eBPF programs in.

[jacob]

I switch C++ compilers without issue all the time. what is your point? its just rambling about non existing issues.

Well maybe you happen to be lucky. But that is an exception, not a rule. Postgresql won't build on freebsd with clang-14, Mozilla has been complaining how trying to accommodate 3 different C++ compilers for their official Firefox builds (VC++ for Windows, G++ for Linux, Clang++ for MacOS) generates substantial additional work, Chromium prefers to ship its own clang, Linux won't work with anything but gcc (and now clang too, but that was a MAJOR undertaking), a number of packages written in C or C++ in the BSD ports tree still have a hard requirement on GCC, etc.

The reality is that trying to write code that is compiler independent takes extra effort which is hardly justified. It was another story when there was a much larger number of relevant platforms than today and each had its own proprietary C compiler (or compilers). But for a new programming language that comes with a compiler which is free, that anyone can have, use, port, adapt, fork etc. at will, which already runs on the most important OSes and architectures (although yes, arch support is still a weakness of Rust compared to C), I really don't see the point of demanding multiple subtly different implementations just because reasons. What practical problem would that solve? I don't see any, but I see a number of problems it would introduce.

Let's also not forget another factor: writing pure "standards compliant" code was much less of a problem back in the 80s or even the 90s. But user expectations have moved on since then and software complexity has increased by orders of magnitude - and for good, justified reasons, so KISS is not the answer. By the same token some of the then-standards have became basically immaterial (like POSIX). You can still write "hello world" in pure standards compliant C, but if you are developing say LibreOffice, choosing your compiler for the project is as important as choosing the UI framework it will use. After all, if someone wants to rebuild it himself, telling him "you must use g++" is a perfectly valid choice.

[cj.wijtmans]

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys that will come up Shakespeare's sonnets (a little better, tbh). What's your point?

I switch C++ compilers without issue all the time. what is your point? its just rambling about non existing issues.

[bug77]

Actually no. Safe means provable. It's almost always impossible to prove that a C++ program is safe.

It depends. I'm pretty sure it's provable if you look at the generated code directly. Not provable from a compiler's point of view, though, which is pretty much the whole point of Rust.

[mdedetrich]

That's one of the thiing rust done right.
Everything of the language, including its specs, RFCs and implementation are public and hosted on github.
Development happens on github and anybody can participate.

The discussion usually happens on zulip and is also publicly available and anybody can join at anytime.

Indeed this is how open source is meant to work. Scala is another language that works this way (I have also personally contributed to Scala) and its liberating to do so.

[jacob]

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys will come up Shakespeare's sonnets (a little better, tbh). What's your point?

Actually no. Safe means provable. It's almost always impossible to prove that a C++ program is safe.

[bug77]

You can turn on strict c++ so no extensions are used. Compilers behaving differently is a good thing as long as they follow the c++ standards. What is the issue?

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys that will come up Shakespeare's sonnets (a little better, tbh). What's your point?

[rogerx]

Well, for a while we tried doing it loud and obnoxiously, but people seemed to hate that even more, so I'm not exactly sure what you want from us.

Your right, Microsoft did a great job of deprecating technology/software every year or so, forcing everybody to buy newer hardware!

How odd?

[GrayShade]

Again not a c++ issue. A tooling issue. While debugging there is plenty of information, sometimes even the code itself is inside the debug information. The issue is that its third party and not by the toolchain itself. The information not being there in a release build is a good thing. Theres memory safety then theres other security issues with too much information in a binary.

Sorry, but I don't think you understand the divide between what a C program is allowed to do and the guarantees the Rust compiler gives you. C doesn't even have the language to describe those guarantees. It's a Whorfian divide.

Take some basic C function:

char * frob(char *, char *, int, int);

If you're lucky, you might get some parameter names. If you've got a bit of programming experience, you might have some ideas about what this function might do. It looks like it takes two pointers and two lengths, so they look like buffers, however:

there's nothing in the code to actually guarantee that
you might not even have the code (it's probably from some ancient library)
you don't know if any or either of the pointers can be NULL
you don't know if these are bytes or characters, and if embedded 0s will have a special meaning or not
you don't know, in principle, which buffer has which length
you don't even know if they are actually buffers, as the code might cast the pointers to something else
lengths are normally size_t, who knows why these are int?
there's no const there. This might be intentional, or just old code, or a programmer who doesn't trust in language restrictions, but you don't know what the function reads and where it writes
there's nothing to say what the return value is -- part of the first buffer, part of the second one, either, something else?
you don't know what the function does. Is it a strcat, a strcpy, a string searching function, some mathematical (vector) op?
you don't know if the function stashes away one of the input pointers, or if it pulls the return value out of a global or a static
finally, regardless of what you answered to these questions, the answers might change when you modify the function, since they're not reflected in the signature

Once again, C and C++ don't have the vocabulary to answer these. The compiler doesn't know the answers. The debug info doesn't have the answers. Even if you're looking at the source code, it's not trivial to answer them.

So here you start adding annotations for a static analyzer. These look like:

_Outptr_result_buffer_​(np) char * frob(_Inout_updates_​(np) char *, _In_reads_(nq) char *, int np, int nq);

This is just one of the possible interpretations above. The annotation syntax is SAL, available in the Microsoft compiler (any mistakes mine). No mechanical process will be able to add these automatically for non-trivial code.

But let's assume you can spend a year to annotate all of your code. What will you do with the libraries you're using? Do you expect your vendors to annotate their? What will you do with the OS APIs? Should everyone project re-do this work? What happens if you switch compilers or static analyzers? And remember that code without annotations (or with the wrong annotations) is still correct C and needs to compile.

So how does Rust help here?

fn frob<'a, 'b>(p: &'a mut [u8], q: &'b [u8]) -> &'a mut [u8]

This is different in some important ways:

Rust buffers (slices) aren't disembodied pointers and lengths, they exist at a language level. Any slice will know its length.
the function declaration clearly says it's modifying the first buffer. If you forget to say mut, the code doesn't compile. If you say mut, you've reserved the right to change the buffer in the future, even if you don't do it today.
the return value is a slice itself, and needs to exist for as long as p exists

C and C++, and every static analyzer I've seen, don't even have the terms to describe a temporal relationship between pointers or references. You can't say "this value must, in every invocation in the program, outlive this other value". You also can't say "this value has thread affinity", which is a story for another day. In Rust you have to describe these complex relationships.

Does Rust still need unsafe code? Yes, but it's going to be limited in scope if you write idiomatic Rust. Can it express every kind of complex relationship? No. Other languages will be more expressive. Is it the language to end all languages? Probably not.

But it solves problems which exist today. Mozilla, Microsoft, Google and Apple all say that 70% or more of their severe bugs are caused by memory- and thread-safety issues, which would not exist in Rust. And that proportion hasn't gone down in the last decade, despite of the various security pushes in each of these companies. This isn't because they don't have good tooling. Microsoft created SAL and made static analysis mandatory in some code bases, IIRC. The reason is that nobody can write a non-trivial amount of correct C or C++ code, and the "sufficiently smart" compiler you believe in will never exist.

[jacob]

You can turn on strict c++ so no extensions are used. Compilers behaving differently is a good thing as long as they follow the c++ standards. What is the issue?

The issue is that "following the C++ standards" is irrelevant; what is relevant is to produce correct working machine code. If two compilers behave differently, you must assume one of those two behaviours, and thus having another incompatible compiler that behaves differently becomes a liability and a source of problems. That it is also "standards compliant" is a meager consolation if the plain fact is that it creates a bug in your program.

Or you resolve yourself to code to the lowest common denominator and/or fill your code with #ifdef's. Development requires considerably more effort, maintainability suffers, and for what? The users of the software couldn't care less that it was written in "standards compliant C++", all they will see is software where bugs take longer to get fixed and new features take much longer to get implemented.

In short, trying to develop software without assuming which compiler it will be built with and with which options is a major PITA. It was a necessary evil (which means it was first and foremost an evil) in the era of proprietary, expensive and closed source compilers and programming languages. In a world where languages, compilers and tools are both free speech and free beer, it's a solution looking for a problem.