Google Wants To See Rust Code In The Linux Kernel, Contracts The Main Developer

[ssokolow]

Poke Poke. Unapproved because of a lot of citations.

[ultimA]

I think they are referring to the state of the object which was moved. You can still access it and that is UB.

What was originally is the following:

1. You create an object in a scope.
2. you move it into a function
3. the function "forgets" the object

In c++ you can move an object, but you can still access it in the original scope. Some compilers warn about that, others not.

In that scenario the moved-from object's lifetime has ended, and this is clearly defined. Neither the move's semantic nor the object's lifetime are undefined, and these were the claims that I rejected. This should be hard to overlook in code because you have to trigger moves explicitly so it is unlikely this will happen to you by mistake, and also you get tool support too to diagnose such mistakes if they do happen.

True, sadly it is only a warning, not a hard compile error. While you can make warnings a hard compile error, this is usually not done in real life, as it will break everything once you use a newer compiler. Luckily my employer tries hard to have a warning free code base.

Even if you don't promote it to an error, you get a warning, and in the scenario that you are worried about, the user actively chooses to ignore this warning. That's the user's fault. I also don't see how promoting warnings to errors and not being able to compile in C++ is much different from Rust not letting you compile the same error for the same reason by default. Puff, you needed to add a compile flag manually, so what? Certainly not a reason why Rust is better than C++ (even though it is, for other/unrelated reasons).

Huh? How can a C++ compiler know when pointer addresses are generated at run time (i.e. via malloc under the hood)?

There is no reason to worry about addresses returned by allocation functions such as malloc (or new), as these are guaranteed to return a pointer with sufficient alignment for any type. The only (rare) exception is when working with SIMD. Other cases, like when doing manual type punning / recasting a pointer from one type to another, the compiler can (and given the right flags, will) warn you.

[CommunityMember]

then it needs to have support for at least one proper trust-able compiler and that is not LLVM.

You keep making that assertion. Please provide a factual and verifiable reference that LLVM is not trust-able.

[krzyzowiec]

Even small projects like some top alternative did not compile, beside that I felt violated on how much the rust toolchain felt like something right out of a javascript npm nightmare.

Yeah because getting dependencies quickly and easily is such a nightmare.

[krzyzowiec]

Correct. And using arbitrary addresses is exactly what makes memory access and management unsafe in general in C and C++.
This is why I was talking about an "opt-in" with C++. Your C++ code can both easily and provably memory safe, but as programmer, you need to be consequent about the use of the features I mentioned above. If you go without using the standard library or write code as it was taught 10 years ago, then yes you will likely introduce some memory-related bugs in any non-trivial program. In Rust I said safety-features are "opt-out", because you explicitly have to introduce unsafe contexts to your code to be able to do bad things, but once you are granted arbitrary pointer manipulation and access, you really can do almost anything (including stuff you shouldn't) like in C.

I completely agree with you, but that in itself is a point in Rust's favor. Modern C++ using standard algorithms is a great language for systems programming, but often you have even experienced people coding like they are writing in C. (raw loops, manually manipulating things instead of using STL, using inheritance, etc.) I think you can blame academia in some sense for poorly teaching the language, and in some ways it may be a cultural thing also, where people are used to doing things in a low level way. At least people don't use new/delete anymore...

There is some benefit in starting with a new language with the proper expectations up front, engrained into the culture at the start. I think if all C++ programmers were made to watch experts like Sean Parent describe the ideal way to program then things would change for the better. Having the compiler straight up yell at you is not a bad alternative though.

[Almindor]

As long as there is no mainstream Rust frontend for GCC, Rust is a non-starter for me.

I develop a commercial C++ Win32 program that I cross-compile from Linux with MinGW (which has been rock solid) and I have yet to find a way to cross-compile Win32 programs with Clang/LLVM without pulling in vc headers and libs from a VS install on Windows. I also do occasional embedded development (arm-none-eabi) and there is no GCC alternative in this space.

Although in theory LLVMs modular nature and features make it well suited to cross-compilation, it's not close to there yet.

If LLVM expanded its arch support and there was a decent way to compile for Win32 with Clang without touching Microsoft IP I'd definitely consider jumping ship but for now it's much simpler to stick to one family of toolchain that does almost everything I need it to.

Hopefully gccrs or a similar project gets some funding to bump it along. I really like Rust but it needs to be unshackled from LLVM for me to take it seriously. I actually like the design of LLVM too, it's just not terribly useful for me at present.

Can anyone explain how Rust in the kernel is going to work when the only backend that supports it doesn't even support all the current Linux architectures?

Umm arm-none-eabi is supported by Rust. I'm running Rust on an arm machine as well as a risc-v little board. It's a "3rd stage support" so basics only (core, no std) but that's what you want usually for embedded anyway.

[krzyzowiec]

Perfectly neglecting the fact that new bugs "less than 1 year old" doesn't mean the bugs were introduced in code adhering to new style. The basic assumption when I claim C++ is memory safe is that you are making proper use of the modern standards. And most code today cannot do that as there are restrictions regarding these due to the historical nature of the old code base that has to be maintained. And even if a code base finally manages to migrate to a new toolset, the old code that already existed still needs to be rewritten.

Exactly right. Working at Google doesn't make you a good programmer. Sean has a good story about a code review he did at Google where he explains how this complex logic involving windows in ChromeOS is really just a rotate. I can't find the clip of the complete story, but he ends up saying that while doing the code review, he actually got the programmer involved to admit that it was a rotate after a few days, but because every code review at Google involves a "mentor" who is senior to the code reviewer, the mentor actually disagreed with him and ended up forcing the original code into the repository. That's why he says he only lasted a year at Google lol. So even "experienced" people aren't necessarily good programmers. We've come a long way since C++ was first introduced, and the problem is that many people are still carrying around the mental baggage of the earlier years.

[oleid]

In that scenario the moved-from object's lifetime has ended, and this is clearly defined. Neither the move's semantic nor the object's lifetime are undefined, and these were the claims that I rejected.

But nobody claimed that.

This should be hard to overlook in code because you have to trigger moves explicitly so it is unlikely this will happen to you by mistake, and also you get tool support too to diagnose such mistakes if they do happen.

Well, yes. If you're lucky you get a warning, if your compiler is new enough.

Even if you don't promote it to an error, you get a warning, and in the scenario that you are worried about, the user actively chooses to ignore this warning. That's the user's fault.

There is a difference between actively ignoring and overlooking. If you don't have a process at work where warning free builds are enforced, it surely is the user's fault. But that is also the case for writing the bugs in the first place.

I also don't see how promoting warnings to errors and not being able to compile in C++ is much different from Rust not letting you compile the same error for the same reason by default. Puff, you needed to add a compile flag manually, so what?

The big advantage of the rust compiler is that things which are obviously wrong are errors people cannot ignore. This is maybe a case of "better defaults".
Usually, big shared code bases don't have -Werror enabled because it breaks compilation for existing (and working code) if you use a different compiler.
The trouble about warnings in C++ code is that every compiler warns about different things in different releases.

There is no reason to worry about addresses returned by allocation functions such as malloc (or new), as these are guaranteed to return a pointer with sufficient alignment for any type.

We were talking about aliasing, not alignment, were we?

https://developers.redhat.com/blog/2020/06/02/the-joys-and-perils-of-c-and-c-aliasing-part-1

[andreano]

True, sadly it is only a warning, not a hard compile error. While you can make warnings a hard compile error, …

Tip: gcc/clang -Werror=switch: I think it should be obligatory

However, the real problem is that default disables this warning/error – a dilemma if you have coding policies that mandate use of default (such as MISRA). Example:

switch (trafficlight) {
    case Red: return "Red";
    case Green: return "Green";

    // Normally -Werror=switch would catch the missing Yellow …
    // … but this policy-mandated `default` silences it :-(
    // Now, we have a runtime error instead of a compile time error!
    default: break;
}
return nullptr;

Rust is a relief in this case, because this was never allowed to compile in the first place, so you don't have dilemmas with differing practices and obsolete policies around it.

[oleid]

Tip: gcc/clang -Werror=switch: I think it should be obligatory

The pain point is that different compilers need different flags on different platforms. And certain compiler versions yield false positives for certain things. I recall using a switch with an enum class and all switch arms issued a return with some value. So basically, any code after the switch statement was unreachable. But still, some gcc version ( I think it was gcc7) forced me to return something after the switch statement as it didn't understand that the return was unreachable. So I could not enable that flag and we had to live with the false positive warning with that compiler version. Which we had to support, as it was part of the toolchain for some platform we still support.


Nevertheless, personally, I think a newer C++ standard should force such things to be errors by default. But it is never going to happen.