Rust’s borrow checker guarantees memory safety at compile time, but some rules—especially around raw pointers—are too subtle for the compiler alone. That’s where Miri comes in. In this post, we’ll walk through two tiny Rust programs: one that Miri accepts, and one that Miri flags as Undefined Behavior. The difference comes down to how Stacked Borrows tracks pointer permissions.
Modern CPUs are fast—but some instructions still hide surprising costs. One of the most misunderstood is DIV. Is 32‑bit division faster than 64‑bit? Does instruction width matter anymore on x86‑64?
To answer this properly, we need more than wall‑clock timers. We need cycle counters, instruction retirement statistics, serialization barriers, and tight control over CPU affinity.
From the administrator command prompt type manage-bde -protectors -get <drive letter>: where
Time to time, and especially for learning purposes, it’s useful to inspect the internal representations that the Rust compiler generates. Below are some notes on how to do that.
One of the most common early borrow‑checker surprises in Rust happens when working with String and references. Developers often expect a borrow to end at the line where it is created — but Rust extends the borrow until the last use of the reference.
Rust’s borrow checker is famously strict, but also famously precise. When something fails to compile due to borrowing rules, the compiler is not guessing — it is analyzing your code through several internal representations, especially HIR (High‑level Intermediate Representation) and MIR (Mid‑level Intermediate Representation).
From time to time, it’s useful to inspect the assembly output generated from Rust code. A common problem is locating a specific piece of Rust code inside the assembly listing. Below is a simple trick to make this much easier.
The Rust team is happy to announce a new version of Rust, 1.95.0. Rust is a programming language empowering everyone to build reliable and efficient software.
A practical look at when to use macros and when to stick with functions in Rust, using a real FFI example (void_ptr) to show why macros don’t magically make your code faster — and why small helper functions often compile to identical machine code.
Rust’s ndarray crate is a powerful foundation for numerical and scientific computing — but just like with any data‑heavy workload, performance depends heavily on how you write your loops.
To explore this, I built a small educational demo that evaluates 10 different techniques for adding two 2D matrices (Array2
Recent releases of FAR (6644 and newer) crashed with ConEmu in attempt to start editor (F4). Below is detailed info and how to fix.
Rust provides strong guarantees about memory safety, alignment, and the behavior of references. However, when you step into the world of low‑level programming — manual allocation, pointer arithmetic, and raw memory manipulation — it becomes your job to uphold these guarantees. One interesting challenge: Can we intentionally place a u32 at an odd address and still read it safely?
Rust is very strict about memory safety, especially when it comes to unaligned data. If you’ve ever worked with byte buffers, binary protocols, FFI, or #[repr(packed)] structs, you’ve probably run into an error like: “error: Reference to field of packed struct is unaligned”
This is Rust politely telling you: “Stop! Creating a reference here would be undefined behavior.”
In this article, we’ll look at why this happens and how Rust’s addr_of! and addr_of_mut! macros let you safely work with potentially unaligned or unsafe memory locations without creating invalid references.
Computing the base‑2 logarithm of an integer (more precisely: finding the index of the highest set bit) is a common operation in systems programming, graphics, data compression, and low‑level algorithms. While Rust provides methods like u32::leading_zeros(), sometimes you may want your own implementation—especially an approach that is branch‑free, fast, and works on all stable targets.
Many engineering teams inherit or maintain systems built on NI Vision (National Instruments Vision Development Module) and Intel IPP (Integrated Performance Primitives). These C libraries are widely used in industrial imaging, automation, robotics, and high‑performance signal processing.