Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST

[Miguel Ojeda]

On Thu, Apr 10, 2025 at 5:14 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> Ignoring MSVC, which is a horrible joke of a compiler (or did Sutter
> finally cluebat that team into building a sane compiler?), there are
> definitely cross compiler STL implementations around.

Definitely, there are, e.g. libc++ and libstdc++, but my point was
that it doesn't happen by accident, i.e. it requires effort (perhaps
even on both sides).

[ As for MSVC, last time I used it (2020?), it was way better compared
to the VC++6 times -- at least they started to try to be conforming,
e.g. all the work behind `/permissive-`, including the two-phase name
lookup I mentioned. They also improved a bunch of thing for C to be
able to build projects out there. ]

> Again, with the exception of MSVC, Boost builds on most C++ compilers
> and is the staging ground for many new library features.

Hmm... I am not sure what you mean -- Boost works with MSVC, and Boost
tries to use standard C++. Even if it may rely on hacks or compiler
extensions at points, Boost does not need to implement e.g. a magic
`std::launder`, and I hope they don't use builtins etc.

> And the old STL (although STL really is far more a library than runtime,
> it being fully optional) will most certainly build on a new compiler
> from the same family.

[ To clarify, by "STL" above I was referring to the Microsoft's STL
project (i.e. they call it STL, but it is the full C++ standard
library). ]

The pure "STL" stuff, i.e. containers and algorithms and such, yeah,
that may not require any magic. Some Rust `core` types and functions
can also be reimplemented in normal Rust too.

> And I know Linus hates on C++ something mighty, but in this parallel
> universe where he doesn't, I would still recommend the kernel to not use
> STL and instead build its own libraries (or borrow some nice pieces here
> and there).

Yeah, we take that approach when needed; e.g. nowadays we don't use
`alloc`, which is another part of the Rust standard library that
contains things like the equivalent to `std::vector`, and we also have
our own equivalents of `core` types sometimes, e.g. our `CStr`.

And, yeah, I agree it would be ideal to be able to reuse/customize
some parts more.

Cheers,
Miguel