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

[andreano]

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.

You are of course correct – the xvalue is well defined.

But here is a philosophical question: If lifetime really was lifetime, why does this compile …

foo(std::move(object));
bar(object);

… as opposed to this?

{
    Object object;
}
bar(object);

I think this shows that C++ chose the wrong move semantics: The xvalue is sort of alive in that its destructor hasn't run yet. I suppose C++ can't forbid you from using it, because the move operator is user implementable, so a masochist could make a valid use out of it. And also because of this user implementability, it's probably not fixable without adding a whole nother move semantic. Which there actually is talk about – "destructive move semantics".

[jacob]

As for the programing side of things. I would love something like Rust, but with actual dynamic libraries like C has. I don't care if you think that is outdated. It's in my opinion an incredibly more robust approach to develop software that lasts and gets maintained for a long time. There is a reason that like 90% of the base system of a given Linux is still C.

I don't think it's "outdated", the problem is technical. The traditional shard libraries model doesn't really work for any language more complex than C. Rust for example is heavily slanted towards generics and parametric polymorphism, which means that many if not most typical library functions need to be monomorphised at build time. It's the same in C++ with templates. If you wanted such libraries to be shared, the monomorphisation and actual compilation process would need to take place upon executable launch when the libs are dynamically linked. The overhead would be absolutely prohibitive, not to mention the potential security implications. Things like COM and GObject basically take the shared library concept as far as it can get, but neither fits naturally in a language like Rust and they don't come for free, so in practice it only makes sense to use them at the boundary between say Rust code and a large third-party framework like GTK or GStreamer. Which is fine by me, that's where using shared libraries brings real benefits. Whether three executables share libpng or link it statically, personally I kinda don't give a damn.

From a package maintainer's point of view, I'm not sure what exactly is your issue with the static linking used by Rust and others. It makes the resulting packages bigger, so what? Memory and storage is cheap and plentiful these days, enough so that we can use it to get other benefits. The idea that static linking is a security liability (you supposedly can't just change a vulnerable lib for all applications to be fixed etc) has been discussed many times and it really is a double edged sword.

[andreano]

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.

FWIW, I think your compiler is concerned with what to do about all the other of the 2³² physically representable values. At least, that is what MISRA C is concerned about (according to some FAQ I read about why the default was obligatory, despite -Werror=switch and all goodness).

Depending on your use case, it might be that you still want the runtime check despite also having the compile time check. A good example is if this value is saved or transmitted, and need to be picked up by a different version of your program.

The solution is just as you described, a return after the switch (never fall for the temptation to use default, though).

[ssokolow]

It's the same in C++ with templates.

From a package maintainer's point of view, I'm not sure what exactly is your issue with the static linking used by Rust and others. It makes the resulting packages bigger, so what? Memory and storage is cheap and plentiful these days, enough so that we can use it to get other benefits. The idea that static linking is a security liability (you supposedly can't just change a vulnerable lib for all applications to be fixed etc) has been discussed many times and it really is a double edged sword.

A couple of relevant things that have been sitting in unapproved purgatory since last night because I was foolish enough to link directly to them:

1. Check out "The impact of C++ templates on library ABI" by Michał Górny for details on your first point.
2. For your second point, check out the "Gotta go deeper" section of Alopex's LetsBeRealAboutDependencies. It gives examples of how C and C++ are plagued with project-specific hand-rolled implementations of things that would be shared packages in things like Rust, and single-header libraries that package maintainers apparently don't complain about not breaking out to match the degree of sharing, deduplication, and vulnerability reporting that you get from Rust packages.

[NobodyXu]

So would a lot of people. The problem is, it's a Hard Problem and an area of active study. Monomorphization (i.e. templates/generics) doesn't play well with dynamic linking, and it's been argued that the C ABI is the highest stable one we had before Swift came along because it's right at the edge of what we know how to make stable without the abstraction tricks Swift uses.

I am curious on how Swift make a stable ABI while other languages like C++ and rust does not.

Can you please provide me with some explanation or some links to the explanation?

Thanks in advance.

[krzyzowiec]

I am curious on how Swift make a stable ABI while other languages like C++ and rust does not.

Can you please provide me with some explanation or some links to the explanation?

Warning: long read.

[NobodyXu]

Warning: long read.

Thank you so much!

I will read through it thoroughly.

[cb88]

A little strange Google wants to support a Mozilla language, when they have Go.

EDIT:
I'm not saying Google should be using Go...

Makes perfect sense, Google is a web company, so is mozilla.... Go, isn't a low level or embedded systems language (its more of a high level one), Rust is... web companies like to use the right tool for the job and unless they have NIH syndrome they don't mind borrowing what others have built for them.

[oleid]

FWIW, I think your compiler is concerned with what to do about all the other of the 2³² physically representable values. At least, that is what MISRA C is concerned about (according to some FAQ I read about why the default was obligatory, despite -Werror=switch and all goodness).

Yeah, I think they use the same switch analysis for enum classes than for enums. For enums it is very easy to mess up the value, for enum classes it is more difficult.

Depending on your use case, it might be that you still want the runtime check despite also having the compile time check. A good example is if this value is saved or transmitted, and need to be picked up by a different version of your program.

In this case, the switch would be handled in the serialization format, i.e. match on the byte value. Blindly calling a cast of an integer to an enum value is never a good thing.

The solution is just as you described, a return after the switch (never fall for the temptation to use default, though).

By the way, I made a quick test. clang, g++ and msvc in all versions warn about the missing return:

https://godbolt.org/z/vfErWbETT

I probably mixed that up with some elder compiler version not warning about the return... maybe. Not sure anymore.

[Alexmitter]

If you want to compile Rust code with Gcc (many people do), you'll be better served by rustc_codegen_gcc.

No, a proper rust frontend for gcc or gtfo.

And sure, rustc and llvm have more people involved, its the nodejs of native development after all and thats not a compliment.