From Types and Programming Languages § 1.2 What Type Systems Are Good For

A safe language is one that protects its own abstractions.
A safe language is completely defined by its programmer’s manual.

Complete abstraction means that users can fully trust the language design, focusing only on the high-level language abstraction layer, without needing to concern themselves with the specific implementation at the hardware level.

High-level languages provide abstractions over physical devices. For example, arrays are abstractions over memory. Programmers expect that arrays can only be modified through explicit update operations (e.g., arr[1] = 1024). “Modifying a variable, and some elements in an array are inexplicably changed” (e.g., buffer overflow attacks) is a manifestation of broken abstraction. This means that programmers must have a detailed understanding of the layout of variables (abstractions provided by high-level languages) in memory (real physical devices) to write programs that meet expectations.

This reminds me of a series of experiments in CSAPP. Since the goal of CSAPP is to examine computer systems from the programmer’s perspective, i.e., viewing hardware from a software perspective, if the programming language used is safe, then we can fully trust the abstractions it provides. Consequently, we cannot see the hardware through the software. If C were safe, then the experiments in CSAPP couldn’t be done 🧐.