Yes, and that’s just what has to be done. Welcome to interfacing with C, it’s been like that for decades.
There are ways these semantics can be annotated via the attribute mechanism in many compilers; this, like nullability, should be added just to improve the ability to statically analyze the existing code and avoid bugs. It can also happen to improve importability of C APIs in other languages, but the primary reason is and should be to make the C code better.
So you write unsafe-to-safe wrapper code for anything you need to interact with—once—so as to encode the interface semantics by hand. Eventually it’s no longer needed because you’ve added annotations to the headers instead. And the kernel gets _better_ because these things can be statically checked and thus have bugs avoided, _regardless of_ the use of Rust.
C doesn't have syntax/typesystem to express ownership, lifetimes and thread safety, but Rust does.
Personally I'd love if C was extended to be able define APIs more precisely, but that's not a realistic option at the moment.
There isn't even any vendor-specific solution to this in C (the hodgepodge of attributes barely scratches the surface). Linux would have to invent its own interface definition language and make C and Rust adopt it. That means more changes for the C maintainers.
The C standard moves very slowly, and avoids making non-trivial changes. I'm still waiting for slices (pointer+length type).
Rust is here today, and won't stop for a dream of C that may or may not happen in 2050.
C has been extended in *exactly* that way using the `__((attribute))__` mechanism in GCC and clang. One does not need to wait for a standards body to do this.
This is one of the ways in which the static analyzer in clang works and they’re very open to further such extensions, which can be easily wrapped in macros so as to not affect compilers that don’t support them.
Do not let the perfect be the enemy of the good. It’s absolutely a realistic option, and it’s one that should be pursued if kernel code quality checking via static analysis is important.
Nothing in GCC or clang that exists today is anywhere near the level of expressiveness that Rust uses in its APIs (e.g. lifetimebound in [1]).
The current problem is not technical, it's maintainers not wanting to even think about another language in their C codebase. Adding non-standard foreign language's semantics on top of C, not supported natively by C compilers, and forced to have an even uglier syntax than Rust's own, would not make C maintainers happy.
You could add an __((attribute))__ that's equivalent to a code comment containing a Rust type, but that also would be strictly worse: less useful to Rust devs, still annoying to C maintainers who wouldn't want to maintain it nor worry about the attributes breaking another compiler for a different language.
I don't think it's feasible to use attributes to add functionality that actually does something meaningful, and doesn't look comically bad at the same time. Look at the zoo of annotations that clang had to add to work around lack of a built-in slice type in C, and that's just a simple thing that's written `[T]` in Rust:
https://clang.llvm.org/docs/BoundsSafety.html
Lifetime annotations are annoyingly noisy and viral even in Rust itself, which has a first-class syntax for them, and generics and type inference to hide the noise. In C they'd be even noisier, and had to be added in more places.
You can't really take safety annotations that are for Rust and reuse them for static analysis of C code itself. They're for a boundary between languages, not for the C implementation. Rust itself is essentially a static analyzer, with everything in the language designed from the ground up for the static analyzer. C wasn't designed for that. If you transplant enough of Rust's requirements to C, you'll make C maintainers write Rust, but using a botched C syntax and a C compiler that doesn't understand the actual language they're writing.
Static analysis is fundamentally limited by C's semantics (limited by undecidability, not mere engineering challenges of implementing a Sufficiently Smart static analyzer). It's not something that can be easily solved with an attribute here and there, because that will be brittle and incomplete[2][3]. Static analysis at that level requires removing a lot of flexibility from C and adding new formalisms, which again would not make C maintainers happy who already resist even tiniest changes of their code to align better with non-C's restrictions.
The same people that are against documenting their APIs when requested by the RfL project would likely reject the idea of adding annotations to C code for (in their eyes) only benefiting RfL.
Maybe you’re too focused on “rival[ing] what Rust can express” and aren’t looking for “better than plain C in a way that improves security and analyzability and would also improve Rust import of C APIs.”
As an example, there are annotation schemes for pairing a size with a buffer pointer, and for indicating a pointer’s ownership transfer. These can then be statically checked, reducing bug risk.
These can also _improve_ interoperability with higher level languages that have such semantics, even if they don’t offer the _complete_ range of semantics possible in those higher level languages.
I don’t have links to share at the moment, but this is ongoing work in places like the clang community.
If these annotations are so powerful why haven't they been adopted in all these years then? Why mention them now as an alternative to Rust? And why not try both and see what sticks?
There are ways these semantics can be annotated via the attribute mechanism in many compilers; this, like nullability, should be added just to improve the ability to statically analyze the existing code and avoid bugs. It can also happen to improve importability of C APIs in other languages, but the primary reason is and should be to make the C code better.
So you write unsafe-to-safe wrapper code for anything you need to interact with—once—so as to encode the interface semantics by hand. Eventually it’s no longer needed because you’ve added annotations to the headers instead. And the kernel gets _better_ because these things can be statically checked and thus have bugs avoided, _regardless of_ the use of Rust.