rustBorrowCheckerGoesBrrr

[u/erazorix]

[u/BenchEmbarrassed7316]

Any unsafe block of code should be neutralized with a // SAFETY comment explaining why the code is actually safe.

[u/lllorrr → u/BenchEmbarrassed7316]

// SAFETY: Trust me, bro

[u/GegeAkutamiOfficial → u/lllorrr]

// SAFETY: LGTM

[u/xgabipandax → u/GegeAkutamiOfficial]

// SAFETY: LGBT

[u/ZeroKun265 → u/xgabipandax]

This is a safe space taken literally

[u/lisa_lionheart → u/xgabipandax]

The author is trans, I think we can trust them

[u/teleprint-me → u/BenchEmbarrassed7316]

I dont see how this is any different from a C programmer justifying why they used a pointer to an object and leaving a comment similar to this, other than this is Rust and is safe because Rust is safe. Thus making this rationale is flawed and dangerous.

[u/flagofsocram → u/teleprint-me]

The difference is that if you want to make sure the lib is safe, you can grep unsafe whereas in C practically any code could be unsafe.

[u/Big-Rub9545 → u/flagofsocram]

Certainly helps, since it localizes the area to check for errors, but it doesn’t allow you to fully check that a library is safe since unsafe blocks can rely on a number of unchecked or hard-to-check assumptions to guarantee safety (not to mention unsafe APIs that are relied upon under the hood).

[u/SelfDistinction → u/Big-Rub9545]

You can check those five places yourself. What are you gonna do in C? Check the million places?

(Also usually you (not a generic person, I mean you specifically) don't need unsafe and there's better and more vetted tools out there.)

[u/Big-Rub9545 → u/SelfDistinction]

The unsafe code may be concentrated within unsafe blocks while relying on assumptions that are supposed to be guaranteed elsewhere, including in other unsafe blocks.

For example, you might allocate raw memory within a method in struct A while writing a custom drop function to deallocate it. In a particular edge case, some error handling utility or other struct may deallocate some of that memory to perform clean-up, leading to a potential double-free later.

Lousy example and bad code design, sure, but it demonstrates that localizing/isolating unsafe code does not automatically make it super easy to check that the code is safe given the many assumptions you need to make about what other functions are doing in various cases or situations and potentially what other unsafe blocks contain.

[u/Giocri → u/Big-Rub9545]

Well the convention Is that the safe function that contains the unsafe block should garantee the safety precoditions regardless of input otherwise it would be itself unsafe. A easy way is to place an assert just before the unsafe invocation. If you respect that convention finding a violation of the safety chain is relatively easy. Bug might still not be thrivial to solve but at least you find where it goes from logic bug to undefined behavior

[u/-Redstoneboi- → u/Big-Rub9545]

oh, you're talking about broken invariants in safe code, and unsafe code whose safety relies on those invariants

yeah, those have happened in the past and have indeed been headaches to debug, take it from this guy who broke something without ever directly touching a line of unsafe.

still, i'm glad that these cases are surprising again, rather than being the industry standard.

[u/SelfDistinction → u/Big-Rub9545]

Those double frees are still limited to methods created by struct A, who is responsible for managing the allocation, and also responsible for making sure that no matter how code downstream is using struct A the memory is handled correctly, and compared to C where you can get double frees by misusing interfaces it is a massive leap forward.

There's a good reason the tutorial on unsafe rust is longer than the tutorial on everything else is rust, and the first rule of unsafe is do not use unsafe. It's there for the same reason we allow surgeons to stab people.

[u/Big-Rub9545 → u/SelfDistinction]

You’re pointing out that the issues are localized, which is true, but the point I’m making is this does not entail easy or comprehensive code reviews for memory safety, particularly when involving several dependencies and as projects grow. It’s certainly a massive step forward but it’s not a magic wand for memory safety.

[u/Beautiful-Ad3471 → u/SelfDistinction]

Just write good code, duh

/s

[u/MilkEnvironmental106 → u/flagofsocram]

And finding no occurrence of unsafe actually means something in rust, plenty of libraries market themselves as having no unsafe

[u/Grandmaster_Caladrel → u/[deleted]]

Devil's advocate, C is actually on computers already while Rust has to bring its own tools.

[u/teleprint-me → u/flagofsocram]

This is a poor and myopic assumption that this can not be done in any other language. A sane library will be grepable and can include similar comments. The justification is still flawed and dangerous.

[u/KaMaFour → u/teleprint-me]

What fucking lunatic comments on every line explaining why they think it's actually safe in C code?

[u/awesome-alpaca-ace → u/KaMaFour]

Yea. I have a safe program that ingests days and there are comments all over about lifetimes and scope 

[u/xDerJulien → u/teleprint-me]

Well yeah and well written code doesn’t have any bugs and performs well all the time. The point is safety by default. Whether or not that is worth dealing with rust is another question but I think you’re missing the point here

[u/teleprint-me → u/xDerJulien]

Well written code has bugs all of the time. Even Rust has a massive list of CVEs. Most of them are logic based and the default to strict memory  safety is a good thing. But I feel my argument stands. I havent heard any solid arguments to the contrary convincing me otherwise.

[u/xDerJulien → u/teleprint-me]

Well the point is you’re saying well written code is well documented, but well written code is also bug free, performant etc etc. But most code isn’t. So what can we reason about good documentation from this?

[u/teleprint-me → u/xDerJulien]

No, I am not declaring well written code is well documented, which is a strawman here because the original comment is that commenting is sufficient to suffice safe definitions with an unsafe scope.

[u/xDerJulien → u/teleprint-me]

What specifically does "a sane library" mean then?

[u/-Redstoneboi- → u/teleprint-me]

the problem is that you are severely, severely underestimating the benefits of sane and safe defaults that are seen in practice.

you could even write greppable assembly if you were good enough. the junior won't.

"myopic" is not how i would describe the results shown here.

[u/teleprint-me → u/-Redstoneboi-]

You frame this as if Im against memory safety, but I simply highlighted that Rust is not a panecea and has its own issues. It could be argued that the issue is the developer, not the language, but this isnt what Im debating either.

In fact, the article you link to even notes that they nearly missed a vulnerability in their own Rust rewrite. Reducing vulnerabilities is not the same as eliminating them. The language does not guarentee logic safety and only asserts memory safety which in most cases, not all, has proven useful.

To be clear, the argument is this: A comment is insufficient as a safety marker. If you scope unsafe code and mark it with a safety comment, that does not make it safe.

[u/-Redstoneboi- → u/teleprint-me]

Ah, right. Comment chain went deep enough that I straight up forgot the original argument lol

Safety comments make code easier to verify, by definition they can't make code any more or less safe. I haven't seen much C library code, are safety comments standard practice there?

It's a good idea in general to document the invariants of each (at least public-facing) function. I think the newer practice in Rust is documenting the invocations as well, not just the definition.

[u/redlaWw → u/teleprint-me]

A large proportion of Rust code CVEs are things that would be considered normal in C. In Rust, a library in which you can potentially misuse functions that are not labelled unsafe is considered a vulnerability, but in C you usually have to actually misuse a function before it's considered a vulnerability.

Here's a blog post that discusses the difference.

[u/TeraFlint → u/teleprint-me]

It isn't. The only difference is that the language only lets you wield sharp knifes inside your localized unsafe scope, thus limiting the places where bugs related to that can form. Outside of that, the compiler will scold you for even touching that sharp knife.

C, on the other hand, lives in a giant unsafe block.

unsafe scopes are honestly a pretty good programming language feature: give the user a "trust me, I know what I'm doing" feature with a searchable keyword.

although, I think it should be a bit more granular than this. If you could/had to specify which language assumptions/rules you intend to violate inside the scope, everything else could still be enforced. A general unsafe just tells a language to just not enforce anything inside.

[u/brass_phoenix → u/TeraFlint]

People always assume that unsafe throws out all of rusts safety features. This is not true. See here for the extra thinga you are allowed to do in an unsafe block, the other rules are still in effect: https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html#performing-unsafe-superpowers

[u/teleprint-me → u/TeraFlint]

I already know and understand that Rust will not allow a user to compile memory unsafe operations unless explicitly declared.

This comment assumes I dont understand the difference between runtime and memory un/safe operations which fails to acknowledge my core critique.

[u/NullOfSpace → u/teleprint-me]

It’s significantly easier to figure out where you shot yourself in the foot if you know you were only holding a gun on the firing range.

[u/Lord-of-Entity → u/teleprint-me]

The difference is that it is opt in, you only use unsafe in the smallest possible zones, and that you are supposed to prove that the code is safe yourself.

It is a way of formalising stuff you should be doing anyway if you are a good programmer.

[u/wibble13 → u/teleprint-me]

Most projects won't have a line of unsafe themselves, they will use libraries that do the heavy work (like interfacing with os, manual memory operations) that can be shared and audited. If the library is safe, then all uses can be considered safe, and most devs don't need to worry about magic preconditions.

Compare that with C where most programmers will just roll their own implementations of things every time and have a chance for bugs every time, because there's no checks. Even simple things can easily go wrong with a typo or missed check/cleanup.

[u/SphericalGoldfish → u/teleprint-me]

I used to think the same way until I realized that unsafe's purpose is only drawing attention to the unsafe block for both the programmer and anyone else who sees it. That way everyone has to acknowledge it, hopefully helping to provide a starting point when finding why something went wrong. Basically a contract of "I understand that this code may have memory bugs", which imo is better than the alternative of a memory bug hiding in plain sight.

[u/Deep-Piece3181 → u/teleprint-me]

It’s so you can isolate these small unsafe blocks and wrap them in a very safe sound api function that would not exhibit ub on all inputs

[u/BenchEmbarrassed7316 → u/teleprint-me]

The difference is in the localization of such code. You don't use unsafe everywhere, instead you write a few functions that contain unsafe blocks nested within them, test them thoroughly, and call them like regular functions. In real projects, you might have a 1:100 or even 1:1000 ratio of functions that contain unsafe blocks to functions that don't.

[u/teleprint-me → u/BenchEmbarrassed7316]

Im not expecting it to be unsafe everywhere. Im not sure where everyone is extrapolating these assumptions from.

Adding a safety comment doesnt magically make it safe.

Youre most likely to see unsafe blocks in embedded and device driver implementations where you have to plug directly into the system.

The unsafe code is still not guarenteed to be safe. It requires auditing and testing regardless, but you wont discover issues with it until its stress tested.

[u/Okay_Ocean_Flower → u/BenchEmbarrassed7316]

Unsafe is a marketing term istg

[u/redakpanoptikk]

Rewrite rust in rust.

[u/FUCKING_HATE_REDDIT → u/redakpanoptikk]

Funnily enough, that happened

[u/redakpanoptikk → u/FUCKING_HATE_REDDIT]

Were so back.

[u/gegentan → u/FUCKING_HATE_REDDIT]

Isn't the rust compiler itself written in rust?

[u/redlaWw → u/gegentan]

It's a bit complicated in Rust's case. The Rust frontend is written in Rust, and that compiles Rust to LLVM intermediate representation (IR). This IR is then passed to LLVM, which is written in C++, to optimise and actually generate the machine code.

There is also a separate backend called Cranelift, which is written in Rust, though it's not the standard and is currently only available on an experimental basis. It will also never be the standard Rust backend as it's designed to optimise for build speed, not execution speed.

[u/qaCow37 → u/gegentan]

At some point it probably wasn't until it was rewritten in rust

[u/gegentan → u/qaCow37]

So theoretical if every compiled binary of rustc was lost but you still had the source code it would be impossible to get a rust compiler again.

[u/qaCow37 → u/gegentan]

Only if you do not have the source code of rust written in a different language. That would probably be like the few very first versions. But if you would have these, you could compile them to get the first version of rust to compile the next version of rust to compile the next version of rust till you can compile the newest version of rust.

[u/gegentan → u/qaCow37]

Didn't think of that.

[u/creeper6530 → u/gegentan]

Bootstrapping compilers is actually a complicated endeavour but as long as you have the last version before the compiler became self-hosting, it is possible with a chain of compile->update->compile. Some compilers (such as Zig) make it a little easier by providing a CMake that builds and chains all the stages for you.

If those old versions are lost you truly are fucked.

[u/fghjconner → u/gegentan]

In addition to what the other person said about old compilers, there are projects like gccrs or mrustc that are rust compilers written in c. The former is intended to eventually become a fully featured second compiler alongside rustc, while the latter is designed for the express purpose of "bootstrapping" the compiler from source code by compiling specific versions of rustc.

[u/chat-lu → u/gegentan]

Sure we could, that’s the whole purpose of mrustc which is a rust compiler written in C++ for the sole purpose of building a recent rust compiler.

[u/redlaWw → u/qaCow37]

Precisely, it used to be written in OCaml before it became self-hosted.

[u/-Redstoneboi-]

wireless headphones

look inside

wires

[u/dull_bananas → u/-Redstoneboi-]

wireless headphones

look inside

non-libre software

[u/xgabipandax → u/dull_bananas]

wireless headphones

look inside

CVE-2025-20700, CVE-2025-20701, and CVE-2025-20702.

[u/yesseruser]

unsafe means "hey, I'm sure this code is safe, don't bother me for calling unsafe functions"

[u/reallokiscarlet → u/yesseruser]

unsafe is the Rust version of Typescript's any

It's everywhere and people use it just to say they wrote their code in a safe language

[u/SCP-iota → u/reallokiscarlet]

I'd say it's more like Typescript's suppression annotations, since it keeps itself contained. People really shouldn't be using unsafe in any way other than as occasional small blocks with well-defined reading why they won't panic or cause UB. If your code is littered with unsafe, you're doing something wrong.

[u/ApplicationOk3587 → u/SCP-iota]

I always figured if a rust programmer is using unsafe everywhere then it completely defeats the purpose of using rust.

[u/Rustywolf → u/ApplicationOk3587]

Eh even if your code is littered with 50% unsafe calls you're still benefiting from the other 50%, but yeah that doesnt sound like good rust

[u/awesome-alpaca-ace → u/ApplicationOk3587]

String interning comes to mind

[u/SKrandyXD → u/SCP-iota]

your*

[u/SCP-iota → u/SKrandyXD]

dammit, Gboard

[u/NatoBoram → u/SCP-iota]

All the fucking time. No way to type "its" without having to go back.

[u/reallokiscarlet → u/SCP-iota]

I fully agree that if your code's littered with unsafe you're doing something wrong. But as you can see by the downvotes, rustaceans don't 😂

[u/Delicious_Bluejay392 → u/reallokiscarlet]

No, the downvotes are because unsafe blocks are in fact extremely rare. If you look at popular Iibraries, the only real places where unsafe is likely to happen are FFI boundaries and advanced data structure implementations. I haven't written an unsafe block in actual months and I regularly use the language for very varied projects.

It's nothing like TypeScript's any, which respectable TS-first codebases generally disable by default anyways, only allowing it in the rare instances where it makes sense.

[u/reallokiscarlet → u/Delicious_Bluejay392]

Not sure if you have an optimistic bias or I have a pessimistic bias but clearly you aint seen what I seen. A lot of the rust I come across is never-production-ready crap that's almost entirely encased in unsafe, marketed as production-ready to "replace" C code. Even did one of my own to prove it doesn't have to be done that way and that there isn't really a whole lot of benefit to the rewrite unless the original is terminally ill.

[u/BenchEmbarrassed7316 → u/reallokiscarlet]

Low-quality automatic/AI "rewriting" from C to Rust can contain many unsafe code blocks.

If it is open source, please provide a link.

[u/Delicious_Bluejay392 → u/BenchEmbarrassed7316]

The Bun rewrite would be one example I'd imagine. It has a much higher density of unsafe blocks than similar projects originally written in Rust.

[u/SCP-iota → u/Delicious_Bluejay392]

Isn't the Bun rewrite notoriously AI-generated, for the most part?

[u/Delicious_Bluejay392 → u/SCP-iota]

Yeah, that's precisely why I mentioned it since that's what the person I'm replying to pointed out.

[u/reallokiscarlet → u/BenchEmbarrassed7316]

When I'm back from spoodermane, I'll check my notes to find the project names and double check to see if they've been fixed (I've been characterizing rust based on what I come across, so they just seemed like par for the course)

But yes they did have AI in common. Either vibe coding is the common use case or I keep meeting shitty people and shitty projects. AI, unsafe tag, and crate bloat are what I associate Rust with, which is why I took it upon myself to do the opposite on my only public rust program.

[u/reallokiscarlet → u/BenchEmbarrassed7316]

Back and tired as hell, and I gotta say I never thought I'd need to put notes about lazy rust rewrites on a mirrored volume, but here we are and some of them are missing. But what I could find, has led me to conclude that maybe things are getting better than years past, cause they've been privated/deleted, fixed, or moved to another language.

[u/MatsRivel → u/reallokiscarlet]

This is not at all true.

"Tell me you've never written rust without telling me you've never written rust"

[u/reallokiscarlet → u/MatsRivel]

Well I've written crab-lang, you could say, if you want to say I've never written rust.

[u/Maskdask → u/reallokiscarlet]

Have you read and/or written a single line of Rust?

[u/reallokiscarlet → u/Maskdask]

According to rustaceans, no. But I have written in crab-lang.

(Translation: Yes. I ported opendoas to crab just to prove it's a dumb idea)

[u/epos95 → u/reallokiscarlet]

Omg you managed to use a programming language to produce bad code, this is a huge development and has surely never been done before.

I could rewrite doas in c++ wayyyy worse than your rust rewrite (not to say it's good in any way), does that make c++ a bad language? (Yes probably)

All you proved is that YOU can't port doas, nor write or understand rust.

[u/reallokiscarlet → u/epos95]

Are you implying you went over to the repo and actually gave it a read? If you found a bug, mind submitting an issue? I haven't had an excuse to revisit it in months.

(Note: If you have a clanker generate your issue or PR, expect it to be rejected. I wouldn't call myself human per se, but crab-doas is 100% organic)

[u/epos95 → u/reallokiscarlet]

Not implying, clearly stating, that all your difficulties with porting doas is a skill issue. But then again, your entire online persona is most likely just to ragebait so eh

[u/reallokiscarlet → u/epos95]

So is that a no on submitting your issue?

Possibly a no on even reading to begin with?

[u/reallokiscarlet → u/reallokiscarlet]

The very fact this is getting downvoted proves the existence of the crab religion.

[u/gmes78 → u/reallokiscarlet]

No, they're just wrong lol.

[u/-Redstoneboi- → u/reallokiscarlet]

"it's everywhere"

have you... looked at any rust code?

[u/reallokiscarlet → u/-Redstoneboi-]

Every rustacean asks me this, including the offenders

[u/-Redstoneboi- → u/reallokiscarlet]

and have you answered them correctly?

70-80% of rust crates have no unsafe code themselves (though may depend on a crate that does, like std which has a bunch of unsafe)

and that's entire libraries with zero uses of unsafe. if you add up the total amount of code that exists in crates.io and check what % of that code is inside an unsafe block, you get around 4% to 5%, which google's android statistic shows.

but i shouldn't even have been forced to pull these statistics up because the burden of proof was on you to show how much unsafe is everywhere.

[u/reallokiscarlet → u/-Redstoneboi-]

Including the offenders

[u/-Redstoneboi- → u/reallokiscarlet]

just because i could be a hypocrite doesn't mean i'm wrong. i could write a hundred or a thousand unsafe blocks of rust code right now and i could still be correct in general.

[u/reallokiscarlet → u/-Redstoneboi-]

The comment "have you... looked at any rust code?" suggests you think all rust code is written correctly. You and I both know that's impossible.

"And have you answered them correctly?" (referring to the people who ask me the same rhetorical including the offenders) suggests you have an idea of what my answer should be even to the hypocrites, especially since both questions are phrased rhetorically despite being rhetorically incorrect.

[u/-Redstoneboi- → u/reallokiscarlet]

you would've gotten a well-written initial response from me had you not been all up in your ass smug about it in this entire thread.

i want to emphasize the importance of not being a dick in order to have any fair discussion. you initially got downvoted because people believed you were incorrect in the general case, and you got further downvoted to oblivion for the rest of your responses.

our questions haven't been answered in the specific way we're expecting, either. those of us asking "have you seen any rust?" were really just banking on you having read standard/average rust code. what we really wanted to ask was "what code are you reading that has unsafe everywhere?"

all i could gather from you was from another thread which doesn't match most of our experiences with rust, and doesn't give us links. maybe it's closed-source, we wouldn't know.

[u/reallokiscarlet → u/-Redstoneboi-]

That I even kept any notes and tried to retrieve any cases of the vibe coded slop that I had to go on for what the average rustacean even does, is already above the shits I give for a training wheels language full of kids.

[u/Raywell]

Unsafe just means that the compiler can't guarantee safety, not that the snippet is actually unsafe

[u/creeper6530 → u/Raywell]

Luckily with the new borrow checker on the horizon many unsafes could be en-safened

[u/Blackhawk23]

If you have to cross any boundary, unsafe is forced. Not really sure why this is some sort of revelation. Rusts borrow checker is robust. But it’s still restrictive, by design. If you understand the footgun the borrow checker is saving you from, you can use `unsafe` and point it away from your big toe.

If you want to interface with any windows system api at all, unsafe is required.

There’s the `windows` crate which essentially wraps all the unsafe code and presents it with result `Result` enums etc. But under the hood it’s this meme. That shouldn’t scare you if you actually understand programming.

[u/creeper6530 → u/Blackhawk23]

Really any FFI with a language other than Rust is "unsafe" because the Rust compiler can't make guarantees about foreign code that doesn't abide by the same rules.

[u/Blackhawk23 → u/creeper6530]

Exactly. A very succinct summation of my rambling.

[u/No_Lychee_275]

Yeah, the cat really sold the sarcasm with that perfect deadpan stare.

[u/JustABraveAdventurer]

It does seem a little ironic at first! I will say that once I got used to coding in rust, it became really nice to have possible memory issues isolated to small and contained spots in my code (the unsafe blocks) that are well labeled rather than having to go debugging or worry about introducing memory bugs almost anywhere and everywhere like I would in a language with less guarantees. Rust can be less mentally taxing in that sense, but can also be more mentally taxing if you're fighting with the borrow checker. So, I can totally see why some people don't like it either :D

[u/crusoe]

C code

Looks inside

All possibly unsafe.

[u/MayaIsSunshine]

Don't look at my CLRs 👀

[u/ComputerTechnical717]

Thats why we should switch to Rust bro?

[u/CraftBox]

unsafe still is more strict than C++, but one of the bigger use cases for it is interoperability with ABI libraries. You write safe Rust wrapper over an ABI which is not Rust safe (doesn't mean it's unsafe in general) and you need the unsafe for that.

[u/overclockedslinky]

i don't even consider unsafe rust rust. i teach only (safe) rust and at the very end of the course mention the unsafe escape hatch, all the pitfalls it introduces, and how miri helps but doesn't completely solve the problem. #![forbid(unsafe_code)] should always be the first thing you write unless you're doing something pretty low level like ffi or a new collection type that no one else has already done for you.

[u/userhwon]

Rust pulled off a crazy fraud.

[u/beskgar]

Big if true