Messages in this thread |  | | From | Miguel Ojeda <> | | Date | Thu, 10 Apr 2025 20:01:04 +0200 | | Subject | Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST |
| |
On Thu, Apr 10, 2025 at 5:14 PM Peter Zijlstra <peterz@infradead.org> 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
|  |