On Tue, Mar 17, 2026 at 08:17:27AM +0100, Miguel Ojeda wrote: > On Tue, Mar 17, 2026 at 6:46 AM Matthew Brost <[email protected]> wrote: > > > > You can do RAII in C - see cleanup.h. Clear object lifetimes and > > ownership are what is important. Disciplined coding is the only to do > > this regardless of language. RAII doesn't help with help with bad object > > models / ownership / lifetime models either. >
I hate cut off in thteads. > "Ownership", "lifetimes" and being "disciplined" *is* what Rust helps > with. That is the whole point (even if there are other advantages). > I get it — you’re a Rust zealot. You can do this in C and enforce the rules quite well. RAII cannot describe ownership transfers of refs, nor can it express who owns what in multi-threaded components, as far as I know. Ref-tracking and ownership need to be explicit. I’m not going to reply to Rust vs C comments in this thread. If you want to talk about ownership, lifetimes, dma-fence enforcement, and teardown guarantees, sure. If you want to build on top of a component that’s been tested on a production driver, great — please join in. If you want to figure out all the pitfalls yourself, well… have fun. Matt > Yes, the cleanup attribute is nice, but even the whole `CLASS` thing > is meant to simplify code. Simplifying code does reduce bugs in > general, but it doesn't solve anything fundamental. Even if we had C++ > and full-fledged smart pointers and so on, it doesn't improve > meaningfully the situation -- one can still mess things up very easily > with them. > > And yes, sanitizers and lockdep and runtime solutions that require to > trigger paths are amazing, but not anywhere close to enforcing > something statically. > > The fact that `unsafe` exists doesn't mean "Rust doesn't solve > anything". Quite the opposite: the goal is to provide safe > abstractions where possible, i.e. we minimize the need for `unsafe`. > And for the cases where there is no other way around it, the toolchain > will force you to write an explanation for your `unsafe` usage. Then > maintainers and reviewers will have to agree with your argument for > it. > > In particular, it is not something that gets routinely (and > implicitly) used every second line like we do in C. > > Cheers, > Miguel
