How to COMPLETELY disable all Rust safety checks?

Gotta say that I agree with @notriddle here. If you aren’t interested in helping someone who is asking a question that’s easily found, that’s okay. Just don’t reply to the thread. There are others who are, and they can take the time to answer. “RTFM” is not how we do things around here.


How about writing the x86 opcodes directly into Rust? In C, you'd do this:

char shellcode[] =

In Rust, perhaps the answer can be found here:


Somewhere about that, yeah. But as someone who learned to program from books (like, the real ones made of dead trees), seeing people unwilling to do even basic research themselves when they have access to some of the best search tools in all of human history is absolutely infuriating.

I had to make do with Altavista and card catalogues. Google giving inconsistent results (that are usually really good irrespective) is about a bazillion times better.

Even whilst Google might not give consistent results, the book’s search should. That was kind of my point: if they’d just looked at the documentation, they’d have answered their own question in about the same time it took them to write the follow-up question, let alone wait for a response. Not looking in the book is literally wasting their own time.

And I really don’t think it’s at all unreasonable to expect people to go to the official website of a language, click the first link on the page (which is “Documentation”) and then click the first non-header link on that page, which is to the book. It’s the very first thing they should find.

Just to be clear: my contention is with the attitude of treating a forum (and the people volunteering to help) as a substitute for said basic research. I think that’s profoundly disrespectful both to the people on the forum, and the people who spend so much time and energy making the docs as good as they are. Plus, like I said, it’s a waste of their own time.


That’s still assuming that @Joe232 knew which “The Book” you were even talking about (it’s The Rust Programming Language, second edition, by the way).

I don’t actually have a problem with copying and pasting a link to the book into a discussion. Teach a newbie how to fish, don’t just feed them. Besides, Steve and associates have done a better job with all the time and iteration than any off-the-cuff description any of us would write.

I do have a problem with assuming that someone already knows what you’re talking about. “Read the book” is not enough information! Don’t just say “the book”, link to it! That’s part of how Google judges the quality of a resource anyway.


That’s a fair criticism.


Aside: Not for links from this forum, though. From your post:

<a href="" rel="nofollow noopener">The Rust Programming Language, second edition</a>

(I wonder if there’s a way to allow-list * for this forum…)


True (and a good thing!), but “RTFM” was @Joe232’s phrase, and I think that was an overreaction.

Moreover, @joe232, you seem to have a habit of starting forum threads to ask questions that aren’t as meaningful as you think they are, and then insisting upon a “simple” answer. In this case, it’s in no one’s best interest to give you a copy-and-paste “recipe” for casting raw pointers, because your question indicates that you don’t understand what Rust’s safety guarantees are, and it’s not clear how casting pointers will help you learn.


Obviously this “program in C” answer is a bit flippant, @joe232, but it’s also the closest thing to a “simple” answer to your question. C is syntactically similar to Rust, and it permits (and, for anything non-trivial, requires) manual unsafe memory manipulation.


I agree that it would be nice to have another version of unsafe that could disable the borrow checker in a few select places. With a little extra verbosity, raw pointers however can do pretty much anything you want. Example of multiple mutable borrows:

fn main() {
    let mut x = 1u64;
    let y = unsafe { &mut *(&mut x as *mut u64) };
    let z = unsafe { &mut *(&mut x as *mut u64) };
    println!("{} {} {}", x, y, z);
    *y = 2;
    println!("{} {} {}", x, y, z);
    *z = 3;
    println!("{} {} {}", x, y, z);

And this is undefined behavior, so your program is free to summon some nasal demons to go with your eaten laundry.

It is, and always will be, undefined behavior to use multiple aliasing &mut to the same data.


Sure, but in practice is it any more dangerous than doing the same in C?

If you have a &mut, yes it’s more dangerous than C. Rust takes advantage of its rules to tell LLVM more things about a &mut than a C compiler does about a pointer. (Violating the &mut aliasing rules in Rust is roughly like violating the restrict aliasing rules in C: extremely dangerous.)


That makes sense… in theory. Is there an example where rustc/llvm will actually perform an optimization that breaks multiple mutable references?

Here is a simple example where “broken” aliasing information leads to an optimization that will return incorrect results.

In foo, the compiler assumes that x and y don’t alias, and as a result it simply forwards the register value holding x as the function’s result - it assumes the store to y has no effect on x, but in reality it does here. The assembly of foo shows the issue:

	movl	$2, (%rsi)
	movl	%edi, %eax

If you instead make foo use raw pointers, you’ll see that the compiler no longer makes aliasing assumptions, and the assembly is different as a result:

	movl	$2, (%rsi)
	movl	(%rdi), %eax <-- this now reads/derefs the %rdi reg, holding `x`'s address

This is probably as basic of an example as one can show, but if you couple these types of “misoptimizations”, you can get all sorts of fun stuff to happen.


Undefined behavior is pretty much ‘catastrophic badness’ from a programmers’ perspective. It’s one thing to play fast and loose with your memory or types, but you’re on a whole different level when you invoke undefined behavior.

When it winds up being a middle-aged dude with mental health issues who nonetheless would like to learn to program, you wind up feeling like a jerk, though. Always worth keeping in mind the story on the other side of the Internet probably isn’t as simple as the story of our frustrations.

1 Like

We are drifting off-topic here people.

There is a simple question in the first post.
The premise of this forum, and our code of conduct, is to assume good intent in the user’s asking.
If you feel the question is worthwhile, answer it. If you feel it is not, move along to other threads where you’ll feel better.

In case you doubt the good intentions, flag it for our tireless moderators, who have thicker skin and more overview on the user. It’s not worth your good temper at best, and troll-feeding at worst.

As for the original question:
@Joe232, the thing you are asking is the programming equivalent if “how do I take the wheels away from my car, but still race it on the highway”. The answer is “you don’t, and you shouldn’t” (not even to “try something out for my own learning experience”)
Rust’s safety guarantees are it’s primary justification to exist, and an essential requirement for the compiler to make sense of your code. Without it, there is no point to using Rust.


You know, that’s a VERY GOOD point. Thanks for that. It’s always good to be reminded that things aren’t always what they at first seem to be. Jumping to conclusions is never good.