2 posts tagged with "Rust"

Preamble​

A programming language--in a hosted environment--has two crucial components: language features and runtime capabilities. For example, features such as traits are language features and it describes the functions (methods) a type may implement, borrow checker which statically analyzes program source to find common errors, and checks that are enforced during compilation are language features. Garbage collection, memory access checks, and other features that are available during program execution are runtime capabilities. We'll look into what happens when a hosted environment closes the standard streams of a Rust program along with masking the /dev directory. This directory is available in most UNIX-like systems, which is what I primarily use.

Introduction: Why Use-After-Free Doesn't Always Crash​

Memory is a crucial topic when it comes to building software. Programs running on historical devices referenced physical memory locations directly, a practice superseded by a dedicated hardware component: the Memory Management Unit (MMU). We now work with virtual memory addresses that is managed by MMU for us^[0]. For a hands-on exploration of how process memory is laid out on macOS ARM64, see the memory post.

malloc and free: Why Accessing Freed Memory Can Silently Succeed​

I recently stumbled across a video regarding the Rust^TM language. The intent of this post is not to look down on the Rust^TM language but to observe a behaviour of a trivial C program. A program fragment was shown in the video, similar to the one shown in Listing 1. After building the executable, we can notice that the program exits normally. But before that, we tried to access a region of memory that was "freed". In contrast, Rust^TM informs this issue during compilation.